We can not run gnulib-tool in the MinGW.

[anlex N]

Hello Teacher!
I value your feedback very much

Nice to meet you. My name is anlex N .

I am a verified google maintainer of popular open source projects.

I am reviewing gnulib
. I can not run
gnulib-tool in the MinGW.

please see the detail in this dicord


How to solve?

gitlog-to-changelog: Improve handling of time zones.

[Collin Funk]

Hi Simon, Bruno, and Paul,

Following this thread from a few months ago [1]. Simon wanted to change
'git-log-to-changelog' so it used dates based on UTC time.

But Bruno said:

> I don't agree with this patch. It misrepresents the dates on which people
> have checked in their commits.
[...]
> There was a problem already before, in gitlog-to-changelog. Namely, what
> if a committer sits in California and the release manager, who creates the
> tarball, sits in England or Germany? The same effect as above would occur.
> But your change now made it even worse: Even the release manager cannot
> override the time zone.

> The real fix, IMO, is to use 'git log --format=fuller', and convert
> the CommitDate (*) by removing the time zone. In the example above:

>  CommitDate: Sat Mar 16 22:29:02 2024 -0700
>  -> 2024-03-16

and then Paul added:

> Emacs has had the tradition of using UTC for ChangeLog dates, so
> please support that as well, as an option.

I've attached a patch that I think deals with these issues. Can you all
look over it for me?

The patch adds a new '--utc' option and changes the default behavior so
that localtime is no longer used. The default behavior invokes git with
options to output ISO 8601 time. For example:

  [commit-hash]:2024-07-02T20:08:08+02:00  Bruno Haible  

  git-merge-changelog: Simplify installation instructions.


That way we can just trim off the time and offset and use the date. When
using '--utc' we can use gmtime like Simon did with his patch.

Let me know if this is okay and I can commit it with documentation
adjustments. BTW, I don't know the time functions very well so there is
probably a better way to do this...

Collin

[1] https://lists.gnu.org/archive/html/bug-gnulib/2024-04/msg00188.html

>From f4ad3c9376a23e10890e1db23e2f28270848f4d2 Mon Sep 17 00:00:00 2001
From: Collin Funk 
Date: Wed, 3 Jul 2024 05:25:54 -0700
Subject: [PATCH] gitlog-to-changelog: Improve handling of time zones.

* build-aux/gitlog-to-changelog: Use the commit date in the committers
timezone by default. Add the --utc option to convert commit times to UTC
before using the date.
(usage): Mention the --utc option.
---
 ChangeLog |  8 
 build-aux/gitlog-to-changelog | 27 +++
 2 files changed, 31 insertions(+), 4 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index fcef360b22..aca200cc13 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2024-07-03  Collin Funk  
+
+	gitlog-to-changelog: Improve handling of time zones.
+	* build-aux/gitlog-to-changelog: Use the commit date in the committers
+	timezone by default. Add the --utc option to convert commit times to UTC
+	before using the date.
+	(usage): Mention the --utc option.
+
 2024-07-02  Bruno Haible  
 
 	git-merge-changelog: Simplify installation instructions.
diff --git a/build-aux/gitlog-to-changelog b/build-aux/gitlog-to-changelog
index 49e7ef95ce..d92eb621da 100755
--- a/build-aux/gitlog-to-changelog
+++ b/build-aux/gitlog-to-changelog
@@ -97,6 +97,7 @@ OPTIONS:
--strip-cherry-pick  remove data inserted by "git cherry-pick";
   this includes the "cherry picked from commit ..." line,
   and the possible final "Conflicts:" paragraph.
+   --utc  convert commit times to UTC before extracting the date
--help   display this help and exit
--versionoutput version information and exit
 
@@ -247,6 +248,7 @@ sub git_dir_option($)
   my $ignore_line;
   my $strip_tab = 0;
   my $strip_cherry_pick = 0;
+  my $utc_commit_time = 0;
   my $srcdir;
   GetOptions
 (
@@ -262,6 +264,7 @@ sub git_dir_option($)
  'ignore-line=s' => \$ignore_line,
  'strip-tab' => \$strip_tab,
  'strip-cherry-pick' => \$strip_cherry_pick,
+ 'utc' => \$utc_commit_time,
  'srcdir=s' => \$srcdir,
 ) or usage 1;
 
@@ -274,10 +277,12 @@ sub git_dir_option($)
   # that makes a correction in the log or attribution of that commit.
   my $amend_code = defined $amend_file ? parse_amend_file $amend_file : {};
 
+  my $commit_time_format = $utc_commit_time ? '%ct' : '%cI';
   my @cmd = ('git',
  git_dir_option $srcdir,
  qw(log --log-size),
- '--pretty=format:%H:%ct  %an  <%ae>%n%n'.$format_string, @ARGV);
+ ("--pretty=format:%H:$commit_time_format"
+  . '  %an  <%ae>%n%n'.$format_string, @ARGV));
   open PIPE, '-|', @cmd
 or die ("$ME: failed to run '". quoted_cmd (@cmd) ."': $!\n"
 . "(Is your Git too old?  Version 1.5.1 or later is required.)\n");
@@ -350,17 +355,31 @@ sub git_dir_option($)
   my $author_line = shift @line;
   defined $author_line
 or die "$ME:$.: unexpected EOF\n";
-  $author_line =~ /^(\d+)  (.*>)$/
+  $author_line =~ /^(\S+)  (.*>)$/
 or die "$ME:$.: Invalid line "
   . "(expected date/author/email):\n$author_line\n";
 
+  # Author  
+  my $author = $2;
+
+  my $commit_date = $1;
+  if ($utc_commit_tim

Re: gitlog-to-changelog: Improve handling of time zones.

[Bruno Haible]

Hi Collin,

> and then Paul added:
> 
> > Emacs has had the tradition of using UTC for ChangeLog dates, so
> > please support that as well, as an option.

and Simon did that, through documentation: In

he added the middle snippet with

env LC_ALL=en_US.UTF-8 TZ=UTC=0

(Btw, is UTC=0 correct? I thought it should be UTC0, per
 ?)

> I've attached a patch that I think deals with these issues. Can you all
> look over it for me?
> 
> The patch adds a new '--utc' option and changes the default behavior so
> that localtime is no longer used.

Both changes are bad.

  * To achieve the UTC display, Simon already showed how to do it:
Set the environment variable TZ to UTC0. If a feature can be achieved
by setting an environment variable, it's overkill to add a command-line
option that does the same thing.

  * It drops the localtime() call, with two bad effects:

  - The principle "Dates and times are always shown relative to the user's
time zone, unless stated otherwise" is violated. This principle
exists because most users don't want to deal with time zones. If you
have a meeting with me at 15:00 GMT, it is *mandatory* that my
calendar displays it to me as 17:00 - and your calendar as 08:00.
"Unless stated otherwise" means, for example, "26 July 2024, 9:00
Saipan time".

  - The dates come out unordered. See:
$ build-aux/gitlog-to-changelog --since=2024-01-01 | grep ^2024
...
2024-06-29  Bruno Haible  
2024-06-28  Collin Funk  
2024-06-29  Bruno Haible  
...
2024-06-26  Paul Eggert  
2024-06-25  Collin Funk  
2024-06-26  Bruno Haible  
...

Bruno

maint.mk: RELEASE leaking into VERSION

[Simon Josefsson via Gnulib discussion list]

Hi,

I ran into this problem today and I'm surprised we haven't seen reports
about it long time ago.  The problem is that if you have the RELEASE
environment variable set when building a package that uses gnulib, the
content of that environment variable leaks into the VERSION makefile
variable, which is often used during builds via make's $(VERSION).

You can reproduce this using, e.g., cppi-1.18 released in 2013:

wget https://ftp.gnu.org/gnu/cppi/cppi-1.18.tar.xz
tar xfz cppi-1.18.tar.xz
cd cppi-1.18
./configure
make check # passes
env RELEASE=foo make check # fails

For me the build failure only occured during Debian CI/CD builds, which
set the RELEASE environment variable to the Debian distribution used
(e.g., "unstable").  Understanding what was happening took some time...

Maybe few people have a RELEASE environment variable, and maybe few
packages depend on the make $(VERSION) variable being correct, which
would explain lack of earlier reports.

The reason all this happens is this code in top/maint.mk:

# If RELEASE_TYPE is undefined, but RELEASE is, use its second word.
# But overwrite VERSION.
ifdef RELEASE
  VERSION := $(word 1, $(RELEASE))
  RELEASE_TYPE ?= $(word 2, $(RELEASE))
endif

This is only ever used during the release process for maintainers,
e.g. make release RELEASE='1.2 stable'.

Can someone think of a simple but backwards compatible fix here?  Is it
possible to only apply the VERSION/RELEASE_TYPE fix when rules related
to 'make release' is invoked?

One of the problem with this code is that it is executed top-level,
which applies to all invocations of 'make' for anyone building projects
using gnulib.  Maybe there are other snippets like this we don't
necessarily want to be executed for each and every user 'make' command.

When you know about this problem, it is easy to work around, for
example: sed -i -e 's,ifdef RELEASE,ifdef GL_RELEASE,' maint.mk

/Simon


signature.asc
Description: PGP signature

Re: We can not run gnulib-tool in the MinGW.

[Simon Josefsson via Gnulib discussion list]

anlex N  writes:

> Hello Teacher!
> I value your feedback very much
>
> Nice to meet you. My name is anlex N .
>
> I am a verified google maintainer of popular open source projects.
>
> I am reviewing gnulib
> . I can not run
> gnulib-tool in the MinGW.
>
> please see the detail in this dicord
> 
>
> How to solve?

Hi.  Please include the details in your bug report, logging into discord
to read things is a bad idea.

I am building libntlm that uses gnulib-tool on Windows with MinGW and it
works fine:

https://gitlab.com/gsasl/libntlm/-/jobs/6629527098

/Simon


signature.asc
Description: PGP signature

Re: gitlog-to-changelog: Improve handling of time zones.

[Simon Josefsson via Gnulib discussion list]

Bruno Haible  writes:

> Hi Collin,
>
>> and then Paul added:
>> 
>> > Emacs has had the tradition of using UTC for ChangeLog dates, so
>> > please support that as well, as an option.
>
> and Simon did that, through documentation: In
> 
> he added the middle snippet with
>
> env LC_ALL=en_US.UTF-8 TZ=UTC=0
>
> (Btw, is UTC=0 correct? I thought it should be UTC0, per
>  ?)

This was based on some patches in Guix, but corrections welcome.

>> I've attached a patch that I think deals with these issues. Can you all
>> look over it for me?
>> 
>> The patch adds a new '--utc' option and changes the default behavior so
>> that localtime is no longer used.
>
> Both changes are bad.
>
>   * To achieve the UTC display, Simon already showed how to do it:
> Set the environment variable TZ to UTC0. If a feature can be achieved
> by setting an environment variable, it's overkill to add a command-line
> option that does the same thing.
>
>   * It drops the localtime() call, with two bad effects:
>
>   - The principle "Dates and times are always shown relative to the user's
> time zone, unless stated otherwise" is violated. This principle
> exists because most users don't want to deal with time zones. If you
> have a meeting with me at 15:00 GMT, it is *mandatory* that my
> calendar displays it to me as 17:00 - and your calendar as 08:00.
> "Unless stated otherwise" means, for example, "26 July 2024, 9:00
> Saipan time".

I agree with all that, HOWEVER the situation is different when the
output is stored in a ChangeLog file that is included in tarballs and
distributed to end users.  Then it is completely inappropriate to use
localtime since that depends on the time zone of the release manager's
laptop.

Isn't the problem because we have two different conflicting use-cases?

1) running gitlog-to-changelog manually to get a human readable
changelog file for easy reading.

2) running gitlog-to-changelog during the release process to create a
long-term archival copy of the changelog, which cannot assume anything
about the reader's time zone and could then just as well either use UTC0
or (maybe better) the local time zone of the original git commit?  For
presentation purposes, I think it is nicer to print '2024-06-29' if the
modification was committed on that day in the local time zone of
whomever did the commit, even if that occured on 2024-06-28 or
2024-06-30 at UTC0.

Thoughts?

/Simon

>   - The dates come out unordered. See:
> $ build-aux/gitlog-to-changelog --since=2024-01-01 | grep ^2024
> ...
> 2024-06-29  Bruno Haible  
> 2024-06-28  Collin Funk  
> 2024-06-29  Bruno Haible  
> ...
> 2024-06-26  Paul Eggert  
> 2024-06-25  Collin Funk  
> 2024-06-26  Bruno Haible  
> ...
>
> Bruno
>
>
>
>
>


signature.asc
Description: PGP signature

Re: maint.mk: RELEASE leaking into VERSION

[Bruno Haible]

Hi Simon,

> Can someone think of a simple but backwards compatible fix here?

I don't think it needs to be backwards-compatible. The maintainers can
afford to change their habits from

  make release RELEASE='1.2 stable'

to

  make release VERSION=1.2 RELEASE_TYPE=stable

> The reason all this happens is this code in top/maint.mk:
> 
> # If RELEASE_TYPE is undefined, but RELEASE is, use its second word.
> # But overwrite VERSION.
> ifdef RELEASE
>   VERSION := $(word 1, $(RELEASE))
>   RELEASE_TYPE ?= $(word 2, $(RELEASE))
> endif

I would remove these few lines, and update top/README-release accordingly.

Bruno

Re: maint.mk: RELEASE leaking into VERSION

[Jim Meyering]

Hi Simon, thanks for diagnosing and reporting that. Did you consider
whether using GNU make's $(origin VAR) function will be sufficient?
I.e., use VERSION only if it's specified on the command line, not
merely if it appears in the environment?

On Wed, Jul 3, 2024 at 10:50 AM Simon Josefsson via Gnulib discussion
list  wrote:
>
> Hi,
>
> I ran into this problem today and I'm surprised we haven't seen reports
> about it long time ago.  The problem is that if you have the RELEASE
> environment variable set when building a package that uses gnulib, the
> content of that environment variable leaks into the VERSION makefile
> variable, which is often used during builds via make's $(VERSION).
>
> You can reproduce this using, e.g., cppi-1.18 released in 2013:
>
> wget https://ftp.gnu.org/gnu/cppi/cppi-1.18.tar.xz
> tar xfz cppi-1.18.tar.xz
> cd cppi-1.18
> ./configure
> make check # passes
> env RELEASE=foo make check # fails
>
> For me the build failure only occured during Debian CI/CD builds, which
> set the RELEASE environment variable to the Debian distribution used
> (e.g., "unstable").  Understanding what was happening took some time...
>
> Maybe few people have a RELEASE environment variable, and maybe few
> packages depend on the make $(VERSION) variable being correct, which
> would explain lack of earlier reports.
>
> The reason all this happens is this code in top/maint.mk:
>
> # If RELEASE_TYPE is undefined, but RELEASE is, use its second word.
> # But overwrite VERSION.
> ifdef RELEASE
>   VERSION := $(word 1, $(RELEASE))
>   RELEASE_TYPE ?= $(word 2, $(RELEASE))
> endif
>
> This is only ever used during the release process for maintainers,
> e.g. make release RELEASE='1.2 stable'.
>
> Can someone think of a simple but backwards compatible fix here?  Is it
> possible to only apply the VERSION/RELEASE_TYPE fix when rules related
> to 'make release' is invoked?
>
> One of the problem with this code is that it is executed top-level,
> which applies to all invocations of 'make' for anyone building projects
> using gnulib.  Maybe there are other snippets like this we don't
> necessarily want to be executed for each and every user 'make' command.
>
> When you know about this problem, it is easy to work around, for
> example: sed -i -e 's,ifdef RELEASE,ifdef GL_RELEASE,' maint.mk
>
> /Simon

Re: maint.mk: RELEASE leaking into VERSION

[Paul Smith]

On Wed, 2024-07-03 at 19:46 +0200, Simon Josefsson via Gnulib
discussion list wrote:
> The reason all this happens is this code in top/maint.mk:
> 
> # If RELEASE_TYPE is undefined, but RELEASE is, use its second word.
> # But overwrite VERSION.
> ifdef RELEASE
>   VERSION := $(word 1, $(RELEASE))
>   RELEASE_TYPE ?= $(word 2, $(RELEASE))
> endif

Personally I find it kind of ... not good to accept values for these
critical variables from the environment in the first place, especially
in a common, unqualified form like that ("RELEASE").

Wouldn't it be better to only allow these to be changed by explicit
assignment on the command line, rather than inherited via the
environment?

Unless the current behavior must be preserved, I would think that
something like:

  RELEASE := $(GNULIB_RELEASE)

coming early in the makefile would be good.  This (a) ensures we don't
use the generic environment variable RELEASE, (b) allows GNULIB_RELEASE
to be obtained from the environment, and (c) allows RELEASE to be
overridden on the command line.


Just a thought.

Re: maint.mk: RELEASE leaking into VERSION

[Jim Meyering]

On Wed, Jul 3, 2024 at 12:16 PM Jim Meyering  wrote:
>
> Hi Simon, thanks for diagnosing and reporting that. Did you consider
> whether using GNU make's $(origin VAR) function will be sufficient?
> I.e., use VERSION only if it's specified on the command line, not
> merely if it appears in the environment?

Here's a proposed (I confess, untested) patch for that:


maint.mk-VERSION-RELEASE.diff
Description: Binary data

Re: maint.mk: RELEASE leaking into VERSION

[Bruno Haible]

Jim Meyering wrote:
> Here's a proposed (I confess, untested) patch for that:

This patch makes things even more complicated.

How about making is simpler, by changing the maintainer's use from

   make release RELEASE='1.2 stable'

to

   make release VERSION=1.2 RELEASE_TYPE=stable

?

Additionally, I don't understand why, after the complicated
business with .tarball-version that the GNUmakefile forces upon
the maintainer, here is *another* way to specify the version?
Why two different mechanisms to do the same thing? Is the
.tarball-version thing not working for you?

Bruno

Re: maint.mk: RELEASE leaking into VERSION

[Simon Josefsson via Gnulib discussion list]

Jim Meyering  writes:

> On Wed, Jul 3, 2024 at 12:16 PM Jim Meyering  wrote:
>>
>> Hi Simon, thanks for diagnosing and reporting that. Did you consider
>> whether using GNU make's $(origin VAR) function will be sufficient?
>> I.e., use VERSION only if it's specified on the command line, not
>> merely if it appears in the environment?
>
> Here's a proposed (I confess, untested) patch for that:

Clever!  That solved the problem elegantly, so I pushed it.  I
sympathize with Bruno's comment about the strange interface of the
RELEASE variable, but I'm pretty used to it and reworking the logic and
documentation doesn't seem motivated right now.

How about a new release of cppi?  I just packaged it for Debian, see
.

/Simon


signature.asc
Description: PGP signature

Re: gitlog-to-changelog: Improve handling of time zones.

[Bruno Haible]

Hi Simon,

> >   * It drops the localtime() call, with two bad effects:
> >
> >   - The principle "Dates and times are always shown relative to the 
> > user's
> > time zone, unless stated otherwise" is violated. This principle
> > exists because most users don't want to deal with time zones. If you
> > have a meeting with me at 15:00 GMT, it is *mandatory* that my
> > calendar displays it to me as 17:00 - and your calendar as 08:00.
> > "Unless stated otherwise" means, for example, "26 July 2024, 9:00
> > Saipan time".
> 
> I agree with all that, HOWEVER the situation is different when the
> output is stored in a ChangeLog file that is included in tarballs and
> distributed to end users.  Then it is completely inappropriate to use
> localtime since that depends on the time zone of the release manager's
> laptop.
> 
> Isn't the problem because we have two different conflicting use-cases?
> 
> 1) running gitlog-to-changelog manually to get a human readable
> changelog file for easy reading.
> 
> 2) running gitlog-to-changelog during the release process to create a
> long-term archival copy of the changelog, which cannot assume anything
> about the reader's time zone and could then just as well either use UTC0
> or (maybe better) the local time zone of the original git commit?  For
> presentation purposes, I think it is nicer to print '2024-06-29' if the
> modification was committed on that day in the local time zone of
> whomever did the commit, even if that occured on 2024-06-28 or
> 2024-06-30 at UTC0.

Yes, listing the use-cases, like you do, is the only way forward here.

And I see that in April [1] I actually proposed the behaviour for 2),
that you agree to and that Collin implemented now.

Still, it troubles me (and I regret that I had not thought of it earlier)
that
  - A list of time points is presented, each occurring in a different
time zone, but without the time zone.
  - As a consequence, the dates are not monotonically increasing.

But based on your use-cases list above, I don't see a better option for 2).

So, can we have
  - 1) with localtime(), as the default behaviour,
  - 2) as implemented by Collin, but enabled through a command-line option,
and then update the second example in the documentation [2], to remove
TZ=UTC=0 and use that command-line option instead?

 Bruno

[1] https://lists.gnu.org/archive/html/bug-gnulib/2024-04/msg00192.html
[2] 
https://www.gnu.org/software/gnulib/manual/html_node/gitlog_002dto_002dchangelog.html

Re: maint.mk: RELEASE leaking into VERSION

[Simon Josefsson via Gnulib discussion list]

Bruno Haible  writes:

> Jim Meyering wrote:
>> Here's a proposed (I confess, untested) patch for that:
>
> This patch makes things even more complicated.
>
> How about making is simpler, by changing the maintainer's use from
>
>make release RELEASE='1.2 stable'
>
> to
>
>make release VERSION=1.2 RELEASE_TYPE=stable
>
> ?
>
> Additionally, I don't understand why, after the complicated
> business with .tarball-version that the GNUmakefile forces upon
> the maintainer, here is *another* way to specify the version?
> Why two different mechanisms to do the same thing? Is the
> .tarball-version thing not working for you?

I think we need one manually invoked rule like 'release-commit' to
create a version tag and set the release type, since this information
cannot come from any other place but the maintainer.  The file
.tarball-version is generated, isn't it?  So I think this is okay:

make release-commit RELEASE='1.2 stable'

We could improve the user interface like with some better naming:

make release-commit VERSION=1.2 TYPE=stable

However I agree with you that it is strange to have to provide the same
information AGAIN when using 'make release'.  I don't like to think
about what happens if the information differ?  I think the command
should simply be:

make release

The version and type should be then be read from the NEWS file, in the
format that 'release-commit' wrote it.  If NEWS isn't updated properly,
fail.

Same for uploading, currently we have to write

  make upload RELEASE='1.2 stable'

and this information could have come from NEWS too.

While we are on the README-release subject, this line garbage always
bothered me:

c=check ve=check-very-expensive; git grep -q "^$ve:\$" && c=$ve
make $c syntax-check distcheck

For easier reading, I think it should be:

make check syntax-check distcheck

and the few packages that have a check-very-expensive rule could patch
the file.

But these are just some opinions, no patches provided :-)

/Simon


signature.asc
Description: PGP signature

Re: gitlog-to-changelog: Improve handling of time zones.

[Simon Josefsson via Gnulib discussion list]

Bruno Haible  writes:

> Hi Simon,
>
>> >   * It drops the localtime() call, with two bad effects:
>> >
>> >   - The principle "Dates and times are always shown relative to the 
>> > user's
>> > time zone, unless stated otherwise" is violated. This principle
>> > exists because most users don't want to deal with time zones. If 
>> > you
>> > have a meeting with me at 15:00 GMT, it is *mandatory* that my
>> > calendar displays it to me as 17:00 - and your calendar as 08:00.
>> > "Unless stated otherwise" means, for example, "26 July 2024, 9:00
>> > Saipan time".
>> 
>> I agree with all that, HOWEVER the situation is different when the
>> output is stored in a ChangeLog file that is included in tarballs and
>> distributed to end users.  Then it is completely inappropriate to use
>> localtime since that depends on the time zone of the release manager's
>> laptop.
>> 
>> Isn't the problem because we have two different conflicting use-cases?
>> 
>> 1) running gitlog-to-changelog manually to get a human readable
>> changelog file for easy reading.
>> 
>> 2) running gitlog-to-changelog during the release process to create a
>> long-term archival copy of the changelog, which cannot assume anything
>> about the reader's time zone and could then just as well either use UTC0
>> or (maybe better) the local time zone of the original git commit?  For
>> presentation purposes, I think it is nicer to print '2024-06-29' if the
>> modification was committed on that day in the local time zone of
>> whomever did the commit, even if that occured on 2024-06-28 or
>> 2024-06-30 at UTC0.
>
> Yes, listing the use-cases, like you do, is the only way forward here.
>
> And I see that in April [1] I actually proposed the behaviour for 2),
> that you agree to and that Collin implemented now.
>
> Still, it troubles me (and I regret that I had not thought of it earlier)
> that
>   - A list of time points is presented, each occurring in a different
> time zone, but without the time zone.
>   - As a consequence, the dates are not monotonically increasing.

I agree.  Re-reading this documentation:

https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html

This suggests to me that the date to use is when the change was
installed/committed.  And since no time zone information is conveyed in
the file, I think the only reasonable way to write a local date/time is
to convert it to UTC0 (or some other non-tz dependent value) before
writing it to ChangeLog.  Anyone reading a changelog file couldn't
possibly know which time zone the committer was in.

That is not how C-x 4 a works, I believe it uses local time zone.  So I
think we will have to live with some inconsistency here.  It can also be
argued that the local date should be used: after all, if I'm committing
something on 2023-12-31 or 2024-01-01 locally, it shouldn't show up as
being done 2024-01-01 or 2023-12-31 which could even have legal
consequences.

> But based on your use-cases list above, I don't see a better option for 2).
>
> So, can we have
>   - 1) with localtime(), as the default behaviour,
>   - 2) as implemented by Collin, but enabled through a command-line option,
> and then update the second example in the documentation [2], to remove
> TZ=UTC=0 and use that command-line option instead?

I'm fine with this -- and maybe while we are it, move a variant of the
gen-ChangeLog rule into maint.mk too?  Ideally it should be
automatically added to dist-hook when the gitlog-to-changelog gnulib
module is used, with some way to use a custom rule if the maint.mk
pre-provided one isn't sufficient.  Right now we duplicate this
Makefile.am snippet in way too many packages.  Then we can more easier
fix things like this by adding a --utc flag to the maint.mk instead of
requiring all maintainers to re-copy the Makefile.am snippet from the
gnulib manual.

/Simon


signature.asc
Description: PGP signature

Re: README-release

[Bruno Haible]

Hi Simon,

> I think we need one manually invoked rule like 'release-commit' to
> create a version tag and set the release type, since this information
> cannot come from any other place but the maintainer.  The file
> .tarball-version is generated, isn't it?

Indeed, build-aux/git-version-gen's comments suggests a Makefile rule
that creates the .tarball-version file during "make dist".

In GNU gettext, I always set the .tarball-version manually. I don't
remember the trouble I got into when I didn't do this.

> However I agree with you that it is strange to have to provide the same
> information AGAIN when using 'make release'.  I don't like to think
> about what happens if the information differ?  I think the command
> should simply be:
> 
> make release

I agree, this would be a more robust interface. And easier if the
maintainer has to try it several times, due to "make distcheck"
failures or similar.

Bruno

Re: gitlog-to-changelog: Improve handling of time zones.

[Bruno Haible]

Simon Josefsson wrote:
> > So, can we have
> >   - 1) with localtime(), as the default behaviour,
> >   - 2) as implemented by Collin, but enabled through a command-line option,
> > and then update the second example in the documentation [2], to remove
> > TZ=UTC=0 and use that command-line option instead?
> 
> I'm fine with this ...

OK.

> > > Still, it troubles me (and I regret that I had not thought of it earlier)
> > that
> >   - A list of time points is presented, each occurring in a different
> > time zone, but without the time zone.
> >   - As a consequence, the dates are not monotonically increasing.
> 
> I agree.  Re-reading this documentation:
> 
> https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html
> 
> This suggests to me that the date to use is when the change was
> installed/committed.  And since no time zone information is conveyed in
> the file, I think the only reasonable way to write a local date/time is
> to convert it to UTC0 (or some other non-tz dependent value) before
> writing it to ChangeLog.  Anyone reading a changelog file couldn't
> possibly know which time zone the committer was in.

OK, this means that instead of changing the example with TZ=UTC0 in the
documentation, we should keep it and _add_ another example, with the new
command-line option that does the "each commit its own time zone" logic.
And let the maintainers pick the one they prefer.

> move a variant of the
> gen-ChangeLog rule into maint.mk too?  Ideally it should be
> automatically added to dist-hook when the gitlog-to-changelog gnulib
> module is used, with some way to use a custom rule if the maint.mk
> pre-provided one isn't sufficient.

I think there's too much variation among GNU packages:
  - Some use a hand-written ChangeLog, some use gitlog-to-changelog.
  - Some have 1 ChangeLog, some have several ones (one per component).
  - Some use --no-cluster, some don't.
  - Some have a build-aux/git-log-fix file, some don't.
  - Some will want to use TZ=UTC0, some will prefer the "each commit its
own time zone" logic.

Bruno

Re: doc/Copyright/request-assign.future is not up to date?

[Bruno Haible]

Ihor Radchenko wrote:
> >> Can you please ask ass...@gnu.org (I guess) to update it?
> >
> > We have already raised the topic with copyright-cl...@fsf.org (which, AFAIK,
> > is identical to ass...@gnu.org). No need to raise it a second time.
> 
> May I know if there is any progress on this issue?

The copyright-cl...@fsf.org is working on it again, now.

Bruno

Re: gitlog-to-changelog: Improve handling of time zones.

[Paul Eggert]

On 7/3/24 14:48, Bruno Haible wrote:

(Btw, is UTC=0 correct? I thought it should be UTC0


It's not portable, although it happens to work on most systems since 
they default to UTC if TZ has a bogus value.


I installed the attached to fix that, and to improve on other issues I 
noticed in that doc file. The basic idea is to shorten the documentation 
by giving the reproducible recipe first, and then telling people what 
line to omit if they don't want reproducibility.From dc2886c010dc34665370be055b2d93ff9aed68d2 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Thu, 4 Jul 2024 00:31:33 +0100
Subject: [PATCH] gitlog-to-changelog: improve doc

---
 doc/gitlog-to-changelog.texi | 70 ++--
 1 file changed, 27 insertions(+), 43 deletions(-)

diff --git a/doc/gitlog-to-changelog.texi b/doc/gitlog-to-changelog.texi
index 137b15fcda..5dc1043e45 100644
--- a/doc/gitlog-to-changelog.texi
+++ b/doc/gitlog-to-changelog.texi
@@ -12,8 +12,8 @@
 @cindex gitlog
 @cindex changelog
 
-Gnulib have a module @code{gitlog-to-changelog} to parse @code{git log}
-output and generate @code{ChangeLog} files, see
+Gnulib has a module @code{gitlog-to-changelog} to parse @code{git log}
+output and generate @file{ChangeLog} files; see
 @ifinfo
 @ref{Change Logs,,,standards}.
 @end ifinfo
@@ -21,61 +21,45 @@ output and generate @code{ChangeLog} files, see
 @url{https://www.gnu.org/prep/standards/html_node/Change-Logs.html}.
 @end ifnotinfo
 
-You would typically use it by extending the @code{dist-hook} in the
-top-level @code{Makefile.am} like this:
+You can use it by extending the @code{dist-hook} rule in the
+top-level @file{Makefile.am} like this:
 
 @example
 dist-hook: gen-ChangeLog
-...
 .PHONY: gen-ChangeLog
 gen-ChangeLog:
-$(AM_V_GEN)if test -e .git; then   \
-$(top_srcdir)/build-aux/gitlog-to-changelog >  \
-$(distdir)/cl-t && \
-@{ rm -f $(distdir)/ChangeLog &&\
-  mv $(distdir)/cl-t $(distdir)/ChangeLog; @}   \
+$(AM_V_GEN)if test -e .git; then   \
+  LC_ALL=en_US.UTF-8 TZ=UTC0   \
+$(top_srcdir)/build-aux/gitlog-to-changelog\
+  > $(distdir)/ChangeLog.tmp &&\
+  mv -f $(distdir)/ChangeLog.tmp $(distdir)/ChangeLog; \
 fi
 @end example
 
 See @code{gitlog-to-changelog --help} for complete documentation.
 
-The tool prints timestamps using @code{localtime}, so its output may be
-different depending on what locale the developer that runs the tool is
-using.  If your project desire reproducible ChangeLog files that doesn't
-depend on locale settings, use something like the following.
+The @code{LC_ALL=en_US.UTF-8 TZ=UTC0} line in this recipe assumes that
+you want to generate reproducible @file{ChangeLog} files that do not
+depend on the developer's locale and time zone.  Omit this line if you
+prefer @file{ChangeLog} files that depend on these developer settings.
 
-@example
-gen-ChangeLog:
-$(AM_V_GEN)if test -e .git; then   \
-env LC_ALL=en_US.UTF-8 TZ=UTC=0\
-$(top_srcdir)/build-aux/gitlog-to-changelog >  \
-$(distdir)/cl-t && \
-@{ rm -f $(distdir)/ChangeLog &&\
-  mv $(distdir)/cl-t $(distdir)/ChangeLog; @}   \
-fi
-@end example
-
-
-If you wish to limit the ChangeLog entries (perhaps for size issues) to
-only contain entries since a particular git tag, use something like the
-following:
+If you wish to limit the @file{ChangeLog} entries (perhaps for size
+issues) to contain only entries since a particular git tag, you can
+use a @code{gen-ChangeLog} rule like the following:
 
 @example
-dist-hook: gen-ChangeLog
-...
 gen_start_ver = 8.31
-.PHONY: gen-ChangeLog
 gen-ChangeLog:
-$(AM_V_GEN)if test -e .git; then   \
-  log_fix="$(srcdir)/build-aux/git-log-fix";   \
-  test -e "$$log_fix"  \
-&& amend_git_log="--amend=$$log_fix"   \
-|| amend_git_log=; \
-  $(top_srcdir)/build-aux/gitlog-to-changelog $$amend_git_log  \
--- v$(gen_start_ver)~.. > $(distdir)/cl-t &&   \
-@{ printf '\n\nSee the source repo for older entries\n' \
-  >> $(distdir)/cl-t &&\
-  rm -f $(distdir)/ChangeLog &&\
-  mv $(distdir)/cl-t $(distdir)/ChangeLog; @}   \
+$(AM_V_GEN)if test -e .git; then   \
+  log_fix='$(srcdi

Re: gitlog-to-changelog: Improve handling of time zones.

[Collin Funk]

Hi Bruno,

Bruno Haible  writes:

> Still, it troubles me (and I regret that I had not thought of it earlier)
> that
>   - A list of time points is presented, each occurring in a different
> time zone, but without the time zone.
>   - As a consequence, the dates are not monotonically increasing.

How do we deal with this for manually written ChangeLogs? For example
two people commiting patches at the same time:

$ TZ='America/Los_Angeles' date
Wed Jul  3 05:08:12 PM PDT 2024

$ TZ='Europe/Berlin' date
Thu Jul  4 02:08:20 AM CEST 2024

> So, can we have
>   - 1) with localtime(), as the default behaviour,
>   - 2) as implemented by Collin, but enabled through a command-line option,
> and then update the second example in the documentation [2], to remove
> TZ=UTC=0 and use that command-line option instead?

I can send a version of that patch if that is agreeable to everyone.

Collin

Re: gitlog-to-changelog: Improve handling of time zones.

[Bruno Haible]

Collin Funk wrote:
> > So, can we have
> >   - 1) with localtime(), as the default behaviour,
> >   - 2) as implemented by Collin, but enabled through a command-line option,
> > and then update the second example in the documentation [2], to remove
> > TZ=UTC=0 and use that command-line option instead?
> 
> I can send a version of that patch if that is agreeable to everyone.

Yes, please. With an added example in the documentation. Thanks!

Bruno

Re: We can not run gnulib-tool in the MinGW.

[anlex N]

me@DESKTOP UCRT64 /e/workspace/github.com/gnu/gnulib
$ ./gnulib-tool --list

I run this command in the gnulib source code, but have no output, why?

me@DESKTOP UCRT64 /e/workspace/github.com/gnu/gnulib
$ ./gnulib-tool --create-testdir --dir=tmp/testdir terminfo
E:/workspace/github.com/gnu/gnulib/gnulib-tool.py: *** not overwriting
destination directory: tmp/testdir
E:/workspace/github.com/gnu/gnulib/gnulib-tool.py: *** Stop.

I also can not run a simple example, why?

Google has no solution to these silly problems. so crazy.

I also run other style gnulib-tool command:

me@DESKTOP UCRT64 /e/workspace/github.com/gnu/gnulib
$ ./gnulib-tool.sh --create-testdir --dir=./tmp/testdir terminfo
./gnulib-tool.sh: *** not overwriting destination directory: ./tmp/testdir
./gnulib-tool.sh: *** Stop.

me@DESKTOP UCRT64 /e/workspace/github.com/gnu/gnulib
$ ./gnulib-tool.sh --create-testdir
--dir='/e/workspace/github.com/gnu/gnulib/tmp/testdir' terminfo
./gnulib-tool.sh: *** not overwriting destination directory:
/e/workspace/github.com/gnu/gnulib/tmp/testdir
./gnulib-tool.sh: *** Stop.

me@DESKTOP UCRT64 /e/workspace/github.com/gnu/gnulib
$ ./gnulib-tool.sh --create-testdir
--dir='E:\workspace\github.com\gnu\gnulib\tmp\testdir' terminfo
./gnulib-tool.sh: *** not overwriting destination directory:
E:\workspace\github.com\gnu\gnulib\tmp\testdir
./gnulib-tool.sh: *** Stop.

Although I run command on the non gnulib source code folder:

me@DESKTOPUCRT64 /e/workspace/github.com/gnu
$ gnulib/gnulib-tool --create-testdir --dir=tmp/testdir terminfo
E:/workspace/github.com/gnu/gnulib/gnulib-tool.py: *** not overwriting
destination directory: tmp/testdir
E:/workspace/github.com/gnu/gnulib/gnulib-tool.py: *** Stop.

These all can not be overwritten, so crazy. oh my god.

Hello simon, I also follow your [.gitlab-ci.yml](
https://gitlab.com/gsasl/libntlm/-/blob/master/.gitlab-ci.yml)


I get these error:

```shell
angle-n@DESKTOP-5HNPO12 UCRT64 /e/workspace/github.com/gnu/gnulib
$ ./gnulib-tool --create-testdir --dir=/tmp/testdir2 terminfo
Module list with included dependencies (indented):
absolute-header
alignasof
alignasof-tests
assert-h
assert-h-tests
attribute
c-ctype
c-ctype-tests
c99
ctype
ctype-tests
extensions
extern-inline
gen-header
havelib
include_next
intprops
intprops-tests
inttypes
inttypes-incomplete
inttypes-tests
isblank
isblank-tests
limits-h
limits-h-tests
multiarch
snippet/_Noreturn
snippet/arg-nonnull
snippet/c++defs
snippet/warn-on-use
ssize_t
std-gnu11
stdbool
stdbool-tests
stddef
stddef-tests
stdint
stdint-tests
stdlib
stdlib-tests
sys_types
sys_types-tests
  terminfo
terminfo-h
terminfo-tests
test-framework-sh
test-framework-sh-tests
unistd
unistd-tests
verify
verify-tests
wchar
wchar-tests
File list:
  build-aux/config.rpath
  lib/_Noreturn.h
  lib/arg-nonnull.h
  lib/assert.in.h
  lib/attribute.h
  lib/c++defs.h
  lib/c-ctype.c
  lib/c-ctype.h
  lib/ctype.in.h
  lib/intprops-internal.h
  lib/intprops.h
  lib/inttypes.in.h
  lib/isblank.c
  lib/limits.in.h
  lib/stddef.in.h
  lib/stdint.in.h
  lib/stdlib.in.h
  lib/sys_types.in.h
  lib/terminfo.h
  lib/tparm.c
  lib/tputs.c
  lib/unistd.c
  lib/unistd.in.h
  lib/verify.h
  lib/warn-on-use.h
  lib/wchar.in.h
  m4/00gnulib.m4
  m4/absolute-header.m4
  m4/assert_h.m4
  m4/c-bool.m4
  m4/codeset.m4
  m4/ctype_h.m4
  m4/curses.m4
  m4/extensions.m4
  m4/extern-inline.m4
  m4/gnulib-common.m4
  m4/host-cpu-c-abi.m4
  m4/include_next.m4
  m4/inttypes.m4
  m4/isblank.m4
  m4/lib-ld.m4
  m4/lib-link.m4
  m4/lib-prefix.m4
  m4/limits-h.m4
  m4/locale-fr.m4
  m4/multiarch.m4
  m4/off64_t.m4
  m4/off_t.m4
  m4/pid_t.m4
  m4/ssize_t.m4
  m4/std-gnu11.m4
  m4/stdalign.m4
  m4/stddef_h.m4
  m4/stdint.m4
  m4/stdlib_h.m4
  m4/sys_types_h.m4
  m4/terminfo.m4
  m4/unistd_h.m4
  m4/warn-on-use.m4
  m4/wchar_h.m4
  m4/wchar_t.m4
  m4/wint_t.m4
  m4/zzgnulib.m4
  tests/init.sh
  tests/macros.h
  tests/signature.h
  tests/test-alignasof.c
  tests/test-assert.c
  tests/test-c-ctype.c
  tests/test-ctype.c
  tests/test-init.sh
  tests/test-intprops.c
  tests/test-inttypes.c
  tests/test-isblank.c
  tests/test-limits-h.c
  tests/test-stdbool.c
  tests/test-stddef.c
  tests/test-stdint.c
  tests/test-stdlib.c
  tests/test-sys_types.c
  tests/test-sys_wait.h
  tests/test-terminfo.c
  tests/test-unistd.c
  tests/test-verify-try.c
  tests/test-verify.c
  tests/test-verify.sh
  tests/test-wchar.c
executing aclocal -I glm4
executing autoconf
executing autoheader
executing touch config.h.in
executing automake --add-missing --copy
configure.ac:8: installing 'build-aux/compile'
configure.ac:4: installing 'build-aux/install-sh'
configure.ac:4: installing 'build-aux/missing'
gllib/Makefile.am: installing 'build-aux/depcomp'
executing aclocal -I ../glm4
executing autoconf
executing autoheader

Re: gitlog-to-changelog: Improve handling of time zones.

[Collin Funk]

Bruno Haible  writes:

>> I can send a version of that patch if that is agreeable to everyone.
>
> Yes, please. With an added example in the documentation. Thanks!

I've pushed the attached patch. Mostly the same as the original but the
default behavior is unchanged. The option is now named
'--commit-timezone'. I'm not very creative so feel free to change it if
you think of something better. :)

I added documentation with an example where me and your time zones
created unordered output in the generated ChangeLog:

2024-06-19  Bruno Haible  
2024-06-18  Collin Funk  
2024-06-19  Bruno Haible  

Hopefully that should make it clear for anyone who wants to avoid that
behavior.

Simon Josefsson  writes:

> That is not how C-x 4 a works, I believe it uses local time zone.  So I
> think we will have to live with some inconsistency here.  It can also be
> argued that the local date should be used: after all, if I'm committing
> something on 2023-12-31 or 2024-01-01 locally, it shouldn't show up as
> being done 2024-01-01 or 2023-12-31 which could even have legal
> consequences.

I wonder if it is worth mentioning to bug-standards. I feel like using
the local time of the committer better represents the "date you applied
the change" as written in the GNU standards mentioned earlier [1].
However, I think I dislike the entries being out of order more...

Collin

[1] https://www.gnu.org/prep/standards/standards.html#Style-of-Change-Logs

>From 4c9664d6f3fcbef8ffd3a2ccb70b694284ee0598 Mon Sep 17 00:00:00 2001
From: Collin Funk 
Date: Wed, 3 Jul 2024 21:55:13 -0700
Subject: [PATCH] gitlog-to-changelog: Add a new --commit-timezone option.

* build-aux/gitlog-to-changelog: Use the date given in the commit time
zone if --commit-timezone is used.
(usage): Mention the new option.
* doc/gitlog-to-changelog.texi (gitlog-to-changelog): Mention the
--commit-timezone and add an invocation example. Add example of date
ordering that may be undesired.
---
 ChangeLog | 10 
 build-aux/gitlog-to-changelog | 29 ++
 doc/gitlog-to-changelog.texi  | 45 +++
 3 files changed, 79 insertions(+), 5 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index a886e25cc2..b19c2a482a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2024-07-03  Collin Funk  
+
+	gitlog-to-changelog: Add a new --commit-timezone option.
+	* build-aux/gitlog-to-changelog: Use the date given in the commit time
+	zone if --commit-timezone is used.
+	(usage): Mention the new option.
+	* doc/gitlog-to-changelog.texi (gitlog-to-changelog): Mention the
+	--commit-timezone and add an invocation example. Add example of date
+	ordering that may be undesired.
+
 2024-07-03  Jim Meyering  
 
 	maintainer-makefile: derive VERSION from RELEASE only from command line
diff --git a/build-aux/gitlog-to-changelog b/build-aux/gitlog-to-changelog
index 49e7ef95ce..32b3a6264c 100755
--- a/build-aux/gitlog-to-changelog
+++ b/build-aux/gitlog-to-changelog
@@ -35,7 +35,7 @@
 eval 'exec perl -wSx "$0" "$@"'
  if 0;
 
-my $VERSION = '2023-06-24 21:59'; # UTC
+my $VERSION = '2024-07-04 04:42'; # UTC
 # The definition above must lie within the first 8 lines in order
 # for the Emacs time-stamp write hook (at end) to update it.
 # If you change this file with Emacs, please let the write hook
@@ -97,6 +97,7 @@ OPTIONS:
--strip-cherry-pick  remove data inserted by "git cherry-pick";
   this includes the "cherry picked from commit ..." line,
   and the possible final "Conflicts:" paragraph.
+   --commit-timezone  use dates respecting the timezone commits were made in.
--help   display this help and exit
--versionoutput version information and exit
 
@@ -247,6 +248,7 @@ sub git_dir_option($)
   my $ignore_line;
   my $strip_tab = 0;
   my $strip_cherry_pick = 0;
+  my $commit_timezone = 0;
   my $srcdir;
   GetOptions
 (
@@ -262,6 +264,7 @@ sub git_dir_option($)
  'ignore-line=s' => \$ignore_line,
  'strip-tab' => \$strip_tab,
  'strip-cherry-pick' => \$strip_cherry_pick,
+ 'commit-timezone' => \$commit_timezone,
  'srcdir=s' => \$srcdir,
 ) or usage 1;
 
@@ -274,10 +277,12 @@ sub git_dir_option($)
   # that makes a correction in the log or attribution of that commit.
   my $amend_code = defined $amend_file ? parse_amend_file $amend_file : {};
 
+  my $commit_time_format = $commit_timezone ? '%cI' : '%ct';
   my @cmd = ('git',
  git_dir_option $srcdir,
  qw(log --log-size),
- '--pretty=format:%H:%ct  %an  <%ae>%n%n'.$format_string, @ARGV);
+ ("--pretty=format:%H:$commit_time_format"
+  . '  %an  <%ae>%n%n'.$format_string, @ARGV));
   open PIPE, '-|', @cmd
 or die ("$ME: failed to run '". quoted_cmd (@cmd) ."': $!\n"
 . "(Is your Git too old?  Version 1.5.1 or later is required.)\n");
@@ -350,17 +355,31 @@ sub git_dir_option($)
   my $author_line =