We can not run gnulib-tool in the MinGW.

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 Min

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

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

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

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 t

maint.mk: RELEASE leaking into VERSION

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, whi

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

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 c

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

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 >

Re: maint.mk: RELEASE leaking into VERSION

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 ha

Re: maint.mk: RELEASE leaking into VERSION

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 Gn

Re: maint.mk: RELEASE leaking into VERSION

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

Re: maint.mk: RELEASE leaking into VERSION

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 envir

Re: maint.mk: RELEASE leaking into VERSION

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 ? Additional

Re: maint.mk: RELEASE leaking into VERSION

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

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

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 wi

Re: maint.mk: RELEASE leaking into VERSION

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 VERSI

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

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

Re: README-release

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 co

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

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

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

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?

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

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 d

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

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

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

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 inst

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

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/gn

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

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 '--comm