Re: Suggestion for cherry-picking to stable branches

Bruno Haible writes: > Sam James wrote: >> It's metadata in addition to the >> commit summary (matching based on a title isn't easy, it's way easier if >> someone says "here's the commits it's based on"; one can give multiple >> such lines). > > It would significantly increase the amount of work

Re: gnulib-tool.sh: Match sorting of gnulib-tool.py in output.

Hi Bruno, On 4/27/24 5:29 PM, Collin Funk wrote: > I'm thinking that this is due to GLTestDir creating a GLEmiter in > __init__() like this: [...] > The 'libtests' value read from the config in self.emitter is > incorrect. This patch seems to support what I was saying here. diff --git

Re: Suggestion for cherry-picking to stable branches

Sam James wrote: > It's metadata in addition to the > commit summary (matching based on a title isn't easy, it's way easier if > someone says "here's the commits it's based on"; one can give multiple > such lines). It would significantly increase the amount of work for maintaining a stable

Re: Suggestion for cherry-picking to stable branches

Bruno Haible writes: >> > easy to compare with the original commit and distinguish >> > branch-only commits from backports. > > You can get limited insights by comparing the ChangeLogs of the > master branch with a stable branch. > > But if what you want is a mechanically verifiable assertion of

Re: Suggestion for cherry-picking to stable branches

Sam James wrote: > The expectation isn't that it directly matches the 'cherry-picked from > ...' commits, but rather that it gives some anchor to compare to / > expresses intent, rather than having to compare just the commit summary > (as those aren't unique). You can get such an "anchor" (a) by

Re: Suggestion for cherry-picking to stable branches

> > easy to compare with the original commit and distinguish > > branch-only commits from backports. You can get limited insights by comparing the ChangeLogs of the master branch with a stable branch. But if what you want is a mechanically verifiable assertion of any kind, I can tell you that

Re: Suggestion for cherry-picking to stable branches

Bruno Haible writes: > Sam James wrote: >> Could I propose that cherry-picks to the stable-XXX branches are done >> with 'git cherry-pick -x'? This is often done in projects following a >> gnulib-like model. >> >> git will append '(cherry picked from commit ...)' to the commit message >> which

Re: gnulib-tool.sh: Match sorting of gnulib-tool.py in output.

On 4/27/24 4:06 PM, Bruno Haible wrote: > The remaining problem now is: > > $ rm -rf ../testdir3; GNULIB_TOOL_IMPL=sh+py ./gnulib-tool > --create-megatestdir --dir=../testdir3 --single-configure stdio > sys_types > ./gnulib-tool: *** gnulib-tool.py produced different files than >

Re: Suggestion for cherry-picking to stable branches

Sam James wrote: > Could I propose that cherry-picks to the stable-XXX branches are done > with 'git cherry-pick -x'? This is often done in projects following a > gnulib-like model. > > git will append '(cherry picked from commit ...)' to the commit message > which makes it easy to compare with

Suggestion for cherry-picking to stable branches

Hi, Could I propose that cherry-picks to the stable-XXX branches are done with 'git cherry-pick -x'? This is often done in projects following a gnulib-like model. git will append '(cherry picked from commit ...)' to the commit message which makes it easy to compare with the original commit and

Re: [PATCH 2/2] nullptr: work around GCC 14 nullptr sentinel bug

Paul Eggert writes: > On 2024-04-27 15:17, Sam James wrote: >> Someone might read this and wrongly think that "GCC 14" >> is broken. >> I'd just omit 14 here. > > Good point as I think some of these bugs are also in GCC 13.x for some > value of x. > > I installed the attached. It's not quite

Re: [PATCH 2/2] nullptr: work around GCC 14 nullptr sentinel bug

On 2024-04-27 15:17, Sam James wrote: Someone might read this and wrongly think that "GCC 14" is broken. I'd just omit 14 here. Good point as I think some of these bugs are also in GCC 13.x for some value of x. I installed the attached. It's not quite what you asked for but I hope it

Re: gnulib-tool.sh: Match sorting of gnulib-tool.py in output.

Hi Collin, > > GNULIB_TOOL_IMPL=sh+py ./gnulib-tool --create-megatestdir > > --dir=testdir2 --single-configure sys_types stdio > > > > Can you double check on your machine? > > I confirm, it passes for me as well now. The remaining problem now is: $ rm -rf ../testdir3;

Re: ac_cv_sys_largefile_opts undocumented?

On Sat, Apr 27, 2024 at 11:42:23PM +0200, Bruno Haible wrote: > dmitrii.pasechnik wrote: > > By the way, ac_cv_sys_largefile_opts isn't fun to use - as sometimes > > it's a plain text, and sometimes flags which should be added to CFLAGS. > > So one has to write things like > > > >

Re: ac_cv_sys_largefile_opts undocumented?

On 2024-04-27 15:39, dmitrii.pasech...@cs.ox.ac.uk wrote: It's for nauty, a well-known program to deal with graph isomorphisms etc. I've made a Gentoo patch herehttps://bugs.gentoo.org/921138 and I wanted to upstream it. Oh my, that is indeed in an undocumented/hacky part of autoconf, one

Re: gnulib-tool.sh: Match sorting of gnulib-tool.py in output.

On 4/27/24 3:22 PM, Bruno Haible wrote: > Thanks. There's a nit, though: These lines do not remove duplicates. > > module_set = set(modules) > modules = [ module > for module in modules > if module in module_set ] Oops... Today isn't my day

Re: ac_cv_sys_largefile_opts undocumented?

On Sat, Apr 27, 2024 at 02:26:24PM -0700, Paul Eggert wrote: > On 2024-04-27 14:06, dmitrii.pasech...@cs.ox.ac.uk wrote: > > Thus I got questions whether a patch for a build system I submitted for > > a project is OK, as it uses an undocumented variable (thus, perhaps, > > unstable). > > Although

Re: gnulib-tool.sh: Match sorting of gnulib-tool.py in output.

Hi Collin, > I've pushed the attached patch Thanks. There's a nit, though: These lines do not remove duplicates. module_set = set(modules) modules = [ module for module in modules if module in module_set ] See: >>> modules = ['a', 'b',

Re: [PATCH 2/2] nullptr: work around GCC 14 nullptr sentinel bug

Paul Eggert writes: > * m4/nullptr.m4 (gl_NULLPTR): Work around GCC bug 114780. > --- > ChangeLog | 3 +++ > doc/gnulib.texi | 4 > m4/nullptr.m4 | 18 -- > 3 files changed, 23 insertions(+), 2 deletions(-) > > diff --git a/ChangeLog b/ChangeLog > index

Re: gnulib-tool.sh: Match sorting of gnulib-tool.py in output.

On 4/27/24 2:29 PM, Bruno Haible wrote: > Also, the SUBDIRS variable in a Makefile.am determines the order in which > the subdirectories are traversed during a build. If a subdirectory has some > chances to fail the build or the tests, it should be mentioned last, so > that the other (more

Re: gnulib-tool: Use the Python implementation by default

On 2024-04-27 11:49, Bruno Haible wrote: - In many recent systems, 'python3' exists and 'python' does not. This includes Ubuntu 23.10 and 24.04. (No idea why it's different on your machine.) Oh, I see I have the python-is-python3 package installed on my Ubuntu platform. I had

Re: ac_cv_sys_largefile_opts undocumented?

dmitrii.pasechnik wrote: > By the way, ac_cv_sys_largefile_opts isn't fun to use - as sometimes > it's a plain text, and sometimes flags which should be added to CFLAGS. > So one has to write things like > > AS_CASE([$ac_cv_sys_largefile_opts], > ["none needed"], [], > ["support not

Re: gnulib-tool.sh: Match sorting of gnulib-tool.py in output.

Hi Collin, > diff -ru testdir2/Makefile.am testdir2-glpy85706/Makefile.am > --- testdir2/Makefile.am 2024-04-27 13:53:51.443692945 -0700 > +++ testdir2-glpy85706/Makefile.am2024-04-27 13:53:33.063660555 -0700 > @@ -2,6 +2,6 @@ > > AUTOMAKE_OPTIONS = 1.14 foreign > > -SUBDIRS =

Re: ac_cv_sys_largefile_opts undocumented?

On 2024-04-27 14:06, dmitrii.pasech...@cs.ox.ac.uk wrote: Thus I got questions whether a patch for a build system I submitted for a project is OK, as it uses an undocumented variable (thus, perhaps, unstable). Although it's poorly designed and not documented and not stable, the patch may be

gnulib-tool.sh: Match sorting of gnulib-tool.py in output.

Hi Bruno, When looking at your bug report I noticed a few lines of the diff are just different orderings. Running: GNULIB_TOOL_IMPL=sh+py ./gnulib-tool --create-megatestdir --dir=testdir2 --single-configure sys_types stdio We see in the diff: diff -ru testdir2/Makefile.am

ac_cv_sys_largefile_opts undocumented?

Hello, I am not 100% sure whether this should go to a gnulib list or to an autoconf list, but anyway, ac_cv_sys_largefile_opts (from a subroutine in AC_SYS_LARGEFILE) is not documented in either gnulib manual, or in autoconf manual. (It is documented in the source). Thus I got questions whether

Re: gnulib-tool.py --create-megatestdir bug

Hi Bruno, On 4/27/24 8:48 AM, Bruno Haible wrote: > Could you please look at this one? I created a megatestdir for some > portability testing, with gnulib-tool.py (of course), and it failed > on macOS: Thanks for the report! I can reproduce it. I have only had a brief look and it looks like

Re: gnulib-tool: Use the Python implementation by default

On 4/27/24 11:49 AM, Bruno Haible wrote: > - In many older systems, 'python3' exists and 'python' exists as well and is > a 2.7.x version. > > I have not seen a single system where 'python' exists, is version 3, and > 'python3' does not exist. There is this PEP which came about with the

Re: printf functions without INT_MAX limitation

Paul Eggert wrote: > Although I don't use Haiku, my impression is that > off_t is 64 bits on Haiku. See, for example, > . Indeed, you're right. Tested on 32-bit Haiku installations from 2017 and 2022. Bruno

Re: gnulib-tool: Use the Python implementation by default

Paul Eggert wrote: > > Are there alternative Python implementations, which could be installed under > > the name 'python3'? > > On the platforms I currently have terminals open on (Fedora 40, Ubuntu > 23.10) it's called 'python'. You can also use 'python3' but I would > suggest trying 'python'

Re: gnulib-tool: Use the Python implementation by default

Hi Pádraig, Thanks for the details. > So this is a general question, unrelated to my particular suggestion. It _is_ related :-) > Possible drop in replacements for the python3 command might be ... > > ... pypy, which separates its implementation version from python language > support

Re: printf functions without INT_MAX limitation

Paul Eggert wrote: > now that you mention off64_t it strikes me that zoff_t would > basically be off64_t, and off64_t has had its own problems: its only use > in apps is to deal with deficient libraries, and it is a pain in > libraries (where its only use is to deal with deficient apps :-). I

Re: gnulib-tool: Use the Python implementation by default

On 2024-04-27 06:32, Bruno Haible wrote: Are there alternative Python implementations, which could be installed under the name 'python3'? On the platforms I currently have terminals open on (Fedora 40, Ubuntu 23.10) it's called 'python'. You can also use 'python3' but I would suggest trying

Re: gnulib-tool: Use the Python implementation by default

On 27/04/2024 14:32, Bruno Haible wrote: Hi Pádraig, +if (python3 --version) >/dev/null 2>/dev/null \ + && case `python3 --version 2>&1` in +Python\ 3.[0-6] | Python\ 3.[0-6].*) false ;; +Python\ 3.*) true ;; +*) false ;; + esac; then It

Re: GNU gnulib: gnulib-tool has become much faster

On 2024-04-27 10:11, Tim Rühsen wrote: Bruno, Dmitry, Collin, thank you so much ! The runtime improvement is amazing :) Likewise. This is very much appreciated, especially on some of the trusty but old and slow hosts that I develop on.

[PATCH 2/2] nullptr: work around GCC 14 nullptr sentinel bug

* m4/nullptr.m4 (gl_NULLPTR): Work around GCC bug 114780. --- ChangeLog | 3 +++ doc/gnulib.texi | 4 m4/nullptr.m4 | 18 -- 3 files changed, 23 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index b30238f934..e341b62968 100644 --- a/ChangeLog +++

[PATCH 1/2] stddef: work around GCC 14 stddef.h bugs

* lib/stddef.in.h: Do nothing if _@GUARD_PREFIX@_STDDEF_H is defined, as stddef.h has already been included. This works around GCC bug 114870. (_GCC_NULLPTR_T): Define if needed to work around GCC bug 114869. * m4/stddef_h.m4 (gl_STDDEF_H, gl_STDDEF_H_DEFAULTS): * modules/stddef (stddef.h):

Re: Fetch from existing gnulib Git repository if needed

Hi Markus, > GNU Octave uses Mercurial as the VCS of its main repository. > Developers are using the bootstrap script of gnulib to automatically clone > its Git repository in a subdirectory of Octave's source tree. The revision > that we'd like to use is set in the bootstrap.conf script.

Re: GNU gnulib: gnulib-tool has become much faster

Bruno, Dmitry, Collin, thank you so much ! The runtime improvement is amazing :) Regards, Tim On 4/26/24 12:14, Bruno Haible wrote: If you are developer on a package that uses GNU gnulib as part of its build system: gnulib-tool has been known for being slow for many years. We have listened

gnulib-tool.py --create-megatestdir bug

Hi Collin, Could you please look at this one? I created a megatestdir for some portability testing, with gnulib-tool.py (of course), and it failed on macOS: Making all in gltests ## ## ## --- Gnulib tests --- ##

Fetch from existing gnulib Git repository if needed

Dear gnulib developers, GNU Octave uses Mercurial as the VCS of its main repository. Developers are using the bootstrap script of gnulib to automatically clone its Git repository in a subdirectory of Octave's source tree. The revision that we'd like to use is set in the bootstrap.conf script.

Re: Modification of environment variables on Windows

Hi Bruno, > > The attached patch avoids those warnings. > > Thanks, but it does not do the right thing: *s[1] accesses the first character > of the string after s. What was meant was to access the second character of > the string at s; this needs to be written as (*s)[1]. Oof. You are absolutely

Re: Modification of environment variables on Windows

Hi Markus, > We recently updated gnulib in GNU Octave to a newer revision > (d4ec02b3cc70cddaaa5183cc5a45814e0afb2292). (Kudos on the impressive speedup > to the bootstrap process.) > > Since then, we are seeing warnings like the following when building for MinGW: > > ../../libgnu/tzset.c: In

Re: gnulib-tool: Use the Python implementation by default

Hi Pádraig, > > +if (python3 --version) >/dev/null 2>/dev/null \ > > + && case `python3 --version 2>&1` in > > +Python\ 3.[0-6] | Python\ 3.[0-6].*) false ;; > > +Python\ 3.*) true ;; > > +*) false ;; > > + esac; then > > It may be

Re: gnulib-tool: Use the Python implementation by default

On 26/04/2024 10:48, Bruno Haible wrote: I committed this patch, which activates the Python rewrite of gnulib-tool for all users who have Python installed, without the need to set any environment variable. I'll make announcements to info-gnu and planet.gnu.org soon. +if (python3

Modification of environment variables on Windows

Dear gnulib developers, We recently updated gnulib in GNU Octave to a newer revision (d4ec02b3cc70cddaaa5183cc5a45814e0afb2292). (Kudos on the impressive speedup to the bootstrap process.) Since then, we are seeing warnings like the following when building for MinGW: ../../libgnu/tzset.c: In

Re: test-sprintf-posix and test-snprintf-posix test failures

Hi Collin, > I would have worked a bit harder and tried to come up with a patch, At this point of the investigations, it's too early for a patch. First, one needs to determine whether it's a bug in Gnulib or a bug in some package we rely on (typically gcc or glibc). In the latter case, we report

Re: test-sprintf-posix and test-snprintf-posix test failures

Hi Bruno, On 4/26/24 10:51 PM, Bruno Haible wrote: > welcome to the daily business of Gnulib test failures and workarounds! Thanks for the welcome! I would have worked a bit harder and tried to come up with a patch, but I am not very familiar with the wide character and multibyte string