Re: future Python evolution

On 4/21/24 16:50, Bruno Haible wrote: Good point. Yes, Python occasionally (rarely?) makes incompatible changes. So, I've now created a continuous integration at [2]. If a Python release is made that breaks gnulib-tool, this CI will notify me shortly afterwards, and we will have time to adapt

Re: future Python evolution

On 4/21/24 16:50, Bruno Haible wrote: Bernhard Voelker wrote: But the concepts of the shell are stuck in the 40-years-ago past. Hehe, Python also had its 33rd birthday already. :-) Good point. Yes, Python occasionally (rarely?) makes incompatible changes. So, I've now created a continuous

Re: beta-tester call draft

On 4/21/24 01:14, Bruno Haible wrote: - install Python on their development machines, I'd guess most hosts have python installed nowadays ... the question is rather which version of it, and how compatible it is: now it's <3.7 which is incompatible (according to your mail), but in future

Re: beta-tester call draft

On 4/20/24 02:22, Bruno Haible wrote: Hi, It's now time to call for beta-testers of the Python gnulib-tool. I plan to post the same text to info-gnu and to planet.gnu.org. Here is a draft. Please comment! findutils results ...

Re: autoreconf --force seemingly does not forcibly update everything

On 4/10/24 4:22 PM, Bruno Haible wrote: Sure, if downstream applies a patch that modifies bootstrap.conf, they need to rerun 'bootstrap'. That goes without saying. I hope downstream then also runs "make check". Sure, full automated QA is in action on all supported platforms. Have a nice day,

Re: autoreconf --force seemingly does not forcibly update everything

On 4/1/24 11:54 PM, Bruno Haible wrote: > Last month, I spent 2 days on prerelease testing of coreutils. If, after > downloading the carefully prepared tarball from ftp.gnu.org, the first > thing a distro does is to throw away the *.m4 files and regenerate the > configure script with their own

Re: Copyright year update

On 1/2/24 01:58, Paul Eggert wrote: On 2024-01-01 16:08, Bernhard Voelker wrote: That commit broke the 'update-copyright' tests, because the test script got messed up. Thanks for reporting that. Turing would have been amused by update-copyright modifying its own test, and then failing

Re: Copyright year update

On 1/1/24 10:33, Simon Josefsson via Gnulib discussion list wrote: Happy hew year! I was greeted with the seasonal copyright_check ./gnulib/lib/version-etc.c maint.mk: out of date copyright in ./gnulib/lib/version-etc.c; update it in several projects, and did a copyright year bump. Happy

Re: [PATCH] maintainer-makefile: Fix syntax-check rules wrt README.

sorry, the attached v2 has the commit message fixed. Have a nice day, BernyFrom 2b63182ece42f65f1ee6b5290fad2901fb7dbe77 Mon Sep 17 00:00:00 2001 From: Bernhard Voelker Date: Sun, 24 Sep 2023 18:13:50 +0200 Subject: [PATCH] maintainer-makefile: Fix syntax-check rules wrt README. * top/maint.mk

[PATCH] maintainer-makefile: Fix syntax-check rules wrt README.

a/ChangeLog b/ChangeLog index 3dabcd0c24..39b043775f 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,13 @@ +2023-09-24 Bernhard Voelker + + maintainer-makefile: Fix syntax-check rules wrt README. + * top/maint.mk (sc_readme_link_install): Change the value of the + variable

Re: Copyright-paperwork-exempt

On 5/31/23 13:57, Bruno Haible wrote: I see this "Copyright-paperwork-exempt" annotation for the first time. I like it, since * The ChangeLog is meant to record this information [1], but when ChangeLogs are generated from git history, this information must obviously be stored in

Re: coreutils CI

On 5/9/23 20:57, Bruno Haible wrote: Bernhard Voelker wrote: I noticed the issue because the following "very-expensive" tests failed (which succeeded with coreutils-9.3): FAIL: tests/rm/ext3-perf FAIL: tests/rm/many-dir-entries-vs-OOM Did you notice these failures by cha

Re: lib/dirfd.c: compiler warning: unused parameter

t failed, which was coreutils commit 941027eeb for the gnulib update, and the went for and back and forth in the gnulib history. The attached coreutils patch updates gnulib to latest to fix the bug. Have a nice day, BernyFrom 131f5c998d5eecfcaed46ea3b5ca2ac93b3737fa Mon Sep 17 00:00:00 2001 From:

Re: stable branches for Gnulib

On 9/10/22 20:36, Bruno Haible wrote: Bernhard Voelker wrote: 1. New upstream / GNU package release. Usually, GNU maintainers pull in the latest changes from gnulib before making a new release. Well, at that time, a lot of platform tests are done, and most problems are found instantly, I'd say

Re: stable branches for Gnulib

On 9/10/22 15:51, Bruno Haible wrote: Maintaining a stable branch is a small amount of work every month. It does not even need to happen on a regular schedule. Even a schedule of 3 months is OK. I don't have a strong opinion about it. Here are just my loose thoughts about it. a) Topic

Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones

On 5/2/22 19:04, Paul Eggert wrote: > On 4/23/22 07:35, Bernhard Voelker wrote: >> lib/gettime-res.c:77:46: error: 'earlier.tv_sec' may be used uninitialized >> in this function \ >> [-Werror=maybe-uninitialized] > > Thanks for reporting that. Although the

Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones

On 4/20/22 20:19, Paul Eggert wrote: > diff --git a/lib/gettime-res.c b/lib/gettime-res.c > index 611f83ad27..bb4d0b191d 100644 > --- a/lib/gettime-res.c > +++ b/lib/gettime-res.c > @@ -53,6 +53,8 @@ gettime_res (void) > >long int hz = TIMESPEC_HZ; >long int r = hz * res.tv_sec +

Re: gawk-5.1.1 bug report

On 4/6/22 10:24, arn...@skeeve.com wrote: > I'll stick to my opinion that && is better here since we're doing > logical tests; the short-circuit nature of && is less important. _ Well, it was an argument to say that & eliminates a

Re: [PATCH] doc: add two missing closing parentheses

On 2/22/22 11:53, Benno Schulenberg wrote: > +2022-02-22 Benno Schulenberg(tiny change) > + > + doc: add two missing closing parentheses > + * doc/regex.texi (Syntax Bits): Add missing closing parenthesis. > + * doc/regex.texi (BSD Regular Expression Compiling): Likewise. Nice

Re: license: comma or semicolon?

On 1/18/22 00:08, Dmitry V. Levin wrote: > On Tue, Jan 04, 2022 at 12:28:34AM +0100, Bernhard Voelker wrote: >> The attached would change it, and shows how the change was done: >> >> Subject: [PATCH] license: fix GPLv3 texts to use a comma instead of >> se

Re: license: comma or semicolon?

On 1/5/22 11:43, Bruno Haible wrote: > Bernhard Voelker wrote: > I have no objection. > >> I'm reluctant because that will most probably also change files auto-updated >> from other projects. > > No problem; in that case, Karl's autoupdate will revert these particu

Re: license: comma or semicolon?

On 1/4/22 21:56, Mike Frysinger wrote: > On 04 Jan 2022 00:28, Bernhard Voelker wrote: >> Run: >> $ git grep -l 'Foundation; either version 3' \ >> | xargs sed -i '/Foundation; either version 3/ s/n; e/n, e/' >> >> * All files using GPLv3: Adjust

Re: license: comma or semicolon?

On 1/3/22 01:17, Mike Frysinger wrote: > according to gnu.org, it should be a comma. > https://www.gnu.org/licenses/gpl-3.0.html#howto The attached would change it, and shows how the change was done: Subject: [PATCH] license: fix GPLv3 texts to use a comma instead of semicolon. See:

Re: test-strerror_r fails on GNU/Hurd

On 1/3/22 02:52, Paul Eggert wrote: > On 1/2/22 16:28, Bernhard Voelker wrote: >> 1073741858: that's 2^30 +34 > > Could it be an address, or part of an address, that is incorrectly > treated as an integer? A mistake like that is quite plausible given the > "does it

Re: test-strerror_r fails on GNU/Hurd

On 1/2/22 21:46, Bruno Haible wrote: > Bernhard Voelker wrote: >> The error in the test-suite.log shows: >> >> FAIL: test-strerror_r >> = >> >> test-strerror_r.c:112: assertion 'ret == ERANGE || ret == EINVAL' failed >> FAIL

Re: license: comma or semicolon?

On 1/3/22 00:46, Bruno Haible wrote: > Bernhard Voelker wrote: >> Comparing some of the license headers, I found that some modules are using a >> comma or >> a semicolon in the 3rd line of the text: > > Why would that matter? > > I'm all for having clea

license: comma or semicolon?

Comparing some of the license headers, I found that some modules are using a comma or a semicolon in the 3rd line of the text: $ ~/gnulib> GIT_PAGER= git grep -B2 -A1 'either version' -- doc/gpl-3.0.texi doc/gpl-3.0.texi-This program is free software: you can redistribute it and/or modify

test-strerror_r fails on GNU/Hurd

Someone reported an unrelated problem for GNU findutils on GNU/Hurd, and in the process of fixing it, I ran into the following problem of 'test-strerror_r': Reproducer: - Prepare a GNU/Hurd VM in VirtualBox: - Download Debian/GNU/Hurd image: see

Re: tests: dis/allow '.' in PATH?

On 11/25/21 00:54, Paul Eggert wrote: > On 11/24/21 15:03, Bernhard Voelker wrote: > Something like the following untested code. This removes all relative > names from PATH, not just '.'. Good idea. Looking at some code from coreutils, I also suggest to test if the entries exist. &g

Re: tests: dis/allow '.' in PATH?

e day, BernyFrom a864d77c8b723fb3aede775c545320cfcedcc8bf Mon Sep 17 00:00:00 2001 From: Bernhard Voelker Date: Wed, 24 Nov 2021 23:59:00 +0100 Subject: [PATCH] test-framework-sh: remove '.' and empty entries from PATH Running tests with '.' in the PATH may yield unspecified results, and is deem

tests: dis/allow '.' in PATH?

GNU findutils got a bug report for a failing test in the testsuite [1]. It turned out that the calling environment had the current directory '.' in PATH. This triggered a warning in `find -execdir ...` and therefore made some tests fail. [1]

Re: close() behavior when there are multiple fds for a socket

On 10/15/21 20:41, Ben Pfaff wrote: > On Fri, Oct 15, 2021 at 11:40 AM Eric Blake wrote: >> On Fri, Oct 15, 2021 at 09:10:04AM -0700, Ben Pfaff wrote: >>> What a bureaucratic organization! The bug report form, once I got a login, >>> requires one to specify a page number and line number, but it

Re: mkstemps is not listed alphabetically in the manual

reporting this. Have a nice day, Berny >From e2a4a093d2d759644a1b5740d5427b53d73f5ab7 Mon Sep 17 00:00:00 2001 From: Bernhard Voelker Date: Sun, 22 Aug 2021 16:06:47 +0200 Subject: [PATCH] doc: fix order of stdlib functions * doc/gnulib.texi (node Glibc stdlib.h): Move mrand48_r aft

Re: announce-gen and OpenPGP key servers

On 7/27/21 11:38 AM, Simon Josefsson via Gnulib discussion list wrote: > Let's discuss and see what we can do. Isn't this what the "release GPG keys" on Savannah are for? Each project maintainer can set them up correctly under "Edit public info":

Re: warnings in unit tests

On 6/8/21 12:57 PM, Bruno Haible wrote: > The difference between lib/ and tests/ is that code in lib/ goes into > the binaries delivered by the packages, and therefore if a package > maintainer makes an effort to silence a warning, we will consider > their patch. Whereas for tests, as I said, it

Re: replacement for 'join'?

On 5/14/21 7:42 PM, Simon Josefsson via Gnulib discussion list wrote: > Certainly! Was anyone working on setting up CI/CD for gnulib on GitLab? > I recall there was a private project for it, but I don't have access. > Any reason for this? I have become rather aquinted with GitLab CI/CD > lately

Re: replacement for 'join'?

On 5/14/21 6:19 PM, Bruno Haible wrote: > Gnulib is a hobbyist, volunteer project. We can not provide the same > level of support as, for example, you do with your company. Therefore — > unless someone comes up and invests the necessary time and money for the > multi-platform continuous

Re: replacement for 'join'?

On 5/12/21 7:58 PM, Simon Josefsson via Gnulib discussion list wrote: > It would be nice to write a 'join' replacement for gnulib-tool, as that > is the only thing that needs coreutils for bootstrapping libidn2 on > alpine. But it is not important, and with your patch things work as > good as

Re: replacement for 'join'?

On 4/6/21 10:45 PM, Bruno Haible wrote: > For small data, I would have transformed the first file to a 'sed' > script, that I would then apply to the second file. But HP-UX 'sed' > has a limit of 100 -e expressions per invocation. I don't have access to HP-UX (and there's none in the GCC compile

Re: replacement for 'join'?

On 4/6/21 4:24 AM, Paul Eggert wrote: > grep -Fvf file2 file1 I started with that, too, but it is problematic because: a) it doesn't do a whole-word search ... and 'grep -w' seems not to be portable, b) it doesn't limit the matching on the key field. And messing with regular expressions seems to

Re: replacement for 'join'?

On 4/5/21 1:06 AM, Bruno Haible wrote: > Alpine Linux does not have the 'join' program. > The GCS [1] don't list it among the essential utilities. FWIW: join(1) is required by POSIX [1]: [1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/join.html > So, what kind of replacement for

Re: lib/libgnu.a not generated

On 3/3/21 3:44 PM, Alejandro Sanchez wrote: > I attempted to import 'quotearg' module into an existing project [...] > changing the existing project files configure.ac [...] > > After that, I ran 'autoreconf' and attempted to build the project. I think `autoreconf` is not sufficient. You have

Re: [PATCH] gendocs.sh: don't overwrite existing index.html

On 3/1/21 8:22 PM, Sergey Poznyakoff wrote: > Actually, the main point is to avoid destroying the existing file with > a meaningless dangling symlink. That being said, I have nothing > against checking for existence of "${PACKAGE}.html" as well. Looks good to me thanks. Have a nice day, Berny

Re: [PATCH] gendocs.sh: don't overwrite existing index.html

On 3/1/21 3:14 PM, Sergey Poznyakoff wrote: > When generating html output, texi2html 5.0 creates index.html > file, instead of $PORJECT.html. Don't overwrite it with dangling > symlink. > -ln -sf ${PACKAGE}.html index.html > +if [ ! -f index.html ]; then > + ln -sf ${PACKAGE}.html

Re: gitlog-to-changelog: output SHA in "empty commit message" warning

On 2/25/21 2:21 AM, Bruno Haible wrote: > Looks good to me. thanks, pushed at: https://git.sv.gnu.org/cgit/gnulib.git/commit/?id=6466d2540a Have a nice day, Berny

gitlog-to-changelog: output SHA in "empty commit message" warning

p 17 00:00:00 2001 From: Bernhard Voelker Date: Thu, 25 Feb 2021 00:58:25 +0100 Subject: [PATCH] gitlog-to-changelog: output SHA in "empty commit message" warning * build-aux/gitlog-to-changelog: Add $sha to above warning diagnostic. --- ChangeLog | 5 + build-

Re: removing permissions for long unused accounts?

On 2/21/21 7:20 PM, Bruno Haible wrote: > The following people still have write access to the gnulib repository [...] Just out of curiosity: where can one see who has write permissions? In the 'memberlist' in Savannah https://savannah.gnu.org/project/memberlist.php?group=gnulib or somewhere

Re: [PATCH] Use https:// instead of git://.

On 1/10/21 5:14 PM, Bruno Haible wrote: > "https://git.savannah.gnu.org/git/myproject.git - >encrypted read-only anonymous smart http access" Nice, then https:// seems indeed to be better than git://. Have a nice day, Berny

Re: [PATCH] Use https:// instead of git://.

On 1/10/21 1:20 PM, Simon Josefsson via Gnulib discussion list wrote: > Using https:// instead of git:// makes this slightly better. Both https:// and git:// URLs are configured to be read-only on the Savannah server, and only the ssh:// variant allows pushing.

[bug #57277] FAIL: test-canonicalize-lgpl with GCC 10

Update of bug #57277 (project findutils): Open/Closed:Open => Closed Release:None => 4.7.0 Fixed Release:None => 4.8.0

Re: AIX7.2: test-fcntl fails when run via AIX make with -j

On 1/7/21 3:04 AM, Bruno Haible wrote: > This indicates that all processes inherit many open file descriptors > (at least, all from 4 to 19). This explains the failures. > > Nothing to worry about. Great, thanks!

Re: bootstrap: cannot find package name in configure.ac

On 1/6/21 10:55 PM, Simon Josefsson via Gnulib discussion list wrote: > Hi. I'm setting GNU SASL up for git-version-gen and bootstrap, and > noticed that bootstrap doesn't handle git-version-gen well. See: > > jas@latte:~$ cat>configure.ac > AC_INIT([GNU SASL], >

AIX7.2: test-fcntl fails when run via AIX make with -j

I notice that 'test-fcntl' fails on AIX7.2 when run from AIX make with any -j value, but succeeds if run both without -j or when run via gmake. Reproducer: Export 'fcntl' module into a tarball, and transfer it to the AIX7.2 host. $ ./gnulib-tool --create-testdir --dir=/tmp/gl-fcntl

Re: printing pid_t values

On 1/6/21 7:00 PM, Bruno Haible wrote: > I don't think there is an issue, because > * The pid_t values occurring on Solaris are in the 5-digit range > (> 0 and likely < 32768). > * On 32-bit platforms, 'int' and 'long' are of the same size, and on > x86_64 and sparc64 the parameter

printing pid_t values

While pid_t is typedef'd to int on GNU/Linux platforms, it is a long on Solaris 11: $ uname -a SunOS gcc-solaris11 5.11 11.3 sun4u sparc SUNW,SPARC-Enterprise $ echo '#include ' | gcc -E - | grep -w pid_t typedef long pid_t; There, one would need the %ld format when printing a pid_t's

Re: test-free: fails with -flto=auto

On 1/3/21 11:21 AM, Bruno Haible wrote: > It's not that slow. I like it :-) Installed as follows: Great, thanks! Have a nice day, Berny

Re: test-free: fails with -flto=auto

Hi Bruno, On 1/3/21 3:06 AM, Bruno Haible wrote: > What was the result of > 'checking whether free is known to preserve errno...' > in your build? "... no" > > If it was 'yes', you've got a problem with the configure test. > > If it was 'no', it seems that you are hitting this GCC bug: >

test-free: fails with -flto=auto

Hi Bruno, wondering why my build failed with the new free-posix module pulled in on openSUSE's build system, I tracked it down to the LTO compiler option. Reproducer: $ ./gnulib-tool --create-testdir --dir=/tmp/gl-free --single-configure free-posix \ && cd /tmp/gl-free \ && env

Re: test-getgroups.c:stringop-overflow warning on newer GCC

On 1/2/21 1:51 PM, Bruno Haible wrote: > 2021-01-02 Bruno Haible > > getgroups test: Avoid warning with glibc >= 2.32 and gcc >= 10. Thanks, works. Have a nice day, Berny

Re: test-getgroups.c:stringop-overflow warning on newer GCC

Hi Bruno, On 1/2/21 2:59 AM, Bruno Haible wrote: > Hi Berny, > >> So it may be an issue with the 10.2.1 version >> ... >> I'm not sure how to proceed from here. > > The most interesting piece of information is the rationale of this > warning (i.e. more precisely why the warning is enabled by

Re: test-getgroups.c:stringop-overflow warning on newer GCC

Hi Bruno, On 1/1/21 1:56 PM, Bruno Haible wrote: > Hi Berny, > > Bernhard Voelker wrote in > <https://lists.gnu.org/archive/html/bug-gnulib/2020-12/msg00090.html>: >> Newer GCC complains about this test: >> >> $ make test-getgroups.o V=1 >>

test-getgroups.c:stringop-overflow warning on newer GCC

Newer GCC complains about this test: $ make test-getgroups.o V=1 depbase=`echo test-getgroups.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ gcc -DHAVE_CONFIG_H -DEXEEXT=\"\" -I. -I.. -DIN_FINDUTILS_GNULIB_TESTS=1 -I. -I. -I.. -I./.. -I../gl/lib -I./.. \ /gl/lib -g -O2 -MT test-getgroups.o

Re: [PATCH] selinux-h: add stubs for selabel_open etc.

On 11/23/20 3:26 AM, Paul Eggert wrote: > On 11/22/20 10:59 AM, Bernhard Voelker wrote: >> selinux.c:257 has a superfluous semicolon after a jump label, >> and a strange indentation: > > The semicolon is required by the C standard, which does not allow a label > before

Re: [PATCH] selinux-h: add stubs for selabel_open etc.

On 11/22/20 7:08 PM, Pádraig Brady wrote: > Non leaky version attached. Thanks. Looks good to me - on system without active SELinux: tested once with and once --without-selinux. Minor nit (from Paul's commit): selinux.c:257 has a superfluous semicolon after a jump label, and a strange

Re: [PATCH] selinux-h: add stubs for selabel_open etc.

00:00 2001 From: Bernhard Voelker Date: Sun, 22 Nov 2020 13:05:29 +0100 Subject: [PATCH] maint: minor cleanup The previous commit introduced a couple of syntax-check failures. * .gitignore (/lib/se-label.h): Add entry to silence the sc_gitignore_missing check. Sort entries in C locale. * po/POTFILES.in

Re: [PATCH] selinux-h: add stubs for selabel_open etc.

On 11/21/20 9:55 PM, Paul Eggert wrote: > Coreutils with --enable-gcc-warnings does not build on Ubuntu 20.10 > because matchpathcon is deprecated in favor of selabel_open etc., > so this patch adds stubs for these functions. Hi Paul, caution - duplicate work ahead:

Re: test-verify.c: avoid -Wmissing-declarations warnings

On 11/3/20 5:20 PM, Bruno Haible wrote: > This was untested, was it? No, it worked here on a gcc-10.2.1 and I'm sure I also tested on something like gcc-7.x, but as I wrote I couldn't find a gcc-5.x installation. Sorry for the inconveniences. Have a nice day, Berny

Re: test-verify.c: avoid -Wmissing-declarations warnings

nd CPPFLAGS="-Wall". Hi Bruno, thanks for the report. Sorry, I didn't test with such old GCC. Should be fixed with the attached patch - I didn't find a gcc-5.* on the compile farm (cfarm.tetaneutral.net). Have a nice day, Berny >From 6d2936ed4668c3dac558aea2623679cb6fd9f485 Mon Sep 17 00

Re: test-verify.c: avoid -Wmissing-declarations warnings

On 10/31/20 12:46 PM, Bruno Haible wrote: > Bernhard Voelker wrote: >> I noticed a new build failure in coreutils when configuring with >> --enable-gcc-warnings. >> GCC is 10.2.1. >> Fixed with the attached. > > While Gnulib generally doesn'

test-verify.c: avoid -Wmissing-declarations warnings

) | ^~~~ cc1: all warnings being treated as errors Have a nice day, Berny >From bc070830dcb1c931472ed38c2b0faa0606a4682d Mon Sep 17 00:00:00 2001 From: Bernhard Voelker Date: Fri, 30 Oct 2020 02:46:44 +0100 Subject: [PATCH] test-verify.c: avoid -Wmissing-declarations warnings * tests/test-verif

Re: [PATCH] selinux-at, selinux-h: port to SELinux 3.1

On 10/20/20 11:18 PM, Bruno Haible wrote: The attached patch changes all occurrences of 'security_context_t' to 'char *'. The main user of these gnulib modules is coreutils, and coreutils switched to the 'char *' type already on 2014-07-01 [1]. Therefore the patch looks fine to me. Bruno [1]

[PATCH] selinux-at, selinux-h: port to SELinux 3.1

occurrences of 'security_context_t' to 'char *'. Have a nice day, Berny >From 687fb693bebd4197f363b60d67263d7ead7cdd08 Mon Sep 17 00:00:00 2001 From: Bernhard Voelker Date: Tue, 20 Oct 2020 00:53:41 +0200 Subject: [PATCH] selinux-at, selinux-h: port to SELinux 3.1 The new release finally depreca

Re: 'fdl' vs. 'fdl-1.3': difference and/or redundant?

On 2020-08-03 22:44, Bernhard Voelker wrote: > On 2020-08-02 00:29, Karl Berry wrote: >> It would need to be applied upstream (maybe by Karl?). >> >> Not me, these days. Writing bug-standa...@gnu.org is the right thing to do. > > I see, thanks. > > --> h

Re: [PATCH] careadlinkat: fix GCC 10 workaround

On 2020-08-17 21:49, Paul Eggert wrote: > Thanks, that's a good idea for GCC 10 since it lets the code allocate the > first > buffer on the stack too, even if warnings are enabled. However, I would > rather > have the code use __attribute__ ((__noinline__)) only if GCC_LINT is defined. > The

Re: [PATCH] careadlinkat: fix GCC 10 workaround

Hi Paul, On 2020-05-11 19:47, Paul Eggert wrote: > +2020-05-11 Paul Eggert > + > + careadlinkat: fix GCC 10 workaround > + * lib/careadlinkat.c (careadlinkat) [GCC_LINT]: > + Massage the code so that it’s closer to what it was before > + the GCC 10.1.0 workaround was

Re: 'fdl' vs. 'fdl-1.3': difference and/or redundant?

On 2020-08-02 00:29, Karl Berry wrote: > It would need to be applied upstream (maybe by Karl?). > > Not me, these days. Writing bug-standa...@gnu.org is the right thing to do. I see, thanks. --> https://lists.gnu.org/r/bug-standards/2020-08/msg0.html Have a nice day, Berny

Re: 'fdl' vs. 'fdl-1.3': difference and/or redundant?

On 2020-07-31 01:38, Bruno Haible wrote: > Bernhard Voelker wrote: >> okay, that means the URL bug should get fixed, right? >> Patch attached. > > This cannot be applied to gnulib. It would need to be applied upstream (maybe > by Karl?). I don't understand. Upstream doe

Re: 'fdl' vs. 'fdl-1.3': difference and/or redundant?

On 2020-07-31 00:04, Bruno Haible wrote: > Bernhard Voelker wrote: >> But once this would be fixed, then the whole 'fdl' module (or the 'fdl-1.3' >> module?) seems to be redundant, doesn't it? >> Couldn't we remove one of them? > > The idea of the 'fdl' module is to p

Re: 'fdl' vs. 'fdl-1.3': difference and/or redundant?

On 2020-07-30 23:48, Bernhard Voelker wrote: > $ diff -u0 doc/fdl.texi doc/fdl-1.3.texi > --- doc/fdl.texi2019-06-23 11:00:48.274552884 +0200 > +++ doc/fdl-1.3.texi2019-06-23 11:00:48.258552658 +0200 > @@ -417 +417 @@ > -@uref{https://www.gnu.org/copyleft/}. &

'fdl' vs. 'fdl-1.3': difference and/or redundant?

The 'fdl' module and its file 'doc/fdl.texi' contains version GFDL 1.3 since Nov 2008 [1][2]. Comparing it to the file 'doc/fdl-1.3.texi' of the 'fdl-1.3' module, there is still this single difference: $ diff -u0 doc/fdl.texi doc/fdl-1.3.texi --- doc/fdl.texi 2019-06-23

Re: [PATCH] tests: pacify gcc -fanalyzer on zerosize_ptr

On 2020-07-05 11:14, Paul Eggert wrote: > On 7/2/20 2:37 PM, Bernhard Voelker wrote: >> The attached fixes it. >> Okay to push? > > Thanks, looks good. Thanks, pushed. Have a nice day, Berny

Re: [PATCH] tests: pacify gcc -fanalyzer on zerosize_ptr

5 Mon Sep 17 00:00:00 2001 From: Bernhard Voelker Date: Thu, 2 Jul 2020 23:11:52 +0200 Subject: [PATCH] tests: avoid shadowing warning * tests/test-memchr.c (main): Give page_boundary variable a tight scope. --- ChangeLog | 5 + tests/test-memchr.c | 9 ++--- 2 files changed, 1

Re: Versioned releases

On 2020-06-04 20:19, Bruno Haible wrote: > Indeed e.g. Debian has a gnulib "package": > https://packages.debian.org/sid/all/gnulib/filelist > > But I think it's a red herring, since basically no one is using gnulib > this way. I agree, it's not really useful: e.g. I'm using

Re: use O_CLOEXEC in more places

On 2020-05-27 20:43, Bruno Haible wrote: > How about module 'fts'? Should the directory fds that it allocates also be > made O_CLOEXEC? +1 I doubt that passing on those fds to any child is wanted/necessary. At least that would be a bug for coreutils (rm,du,chmod,chgrp,chcon) and findutils (find).

Re: doc/gnulib-intro.texi: A "to" is missing in a sentence.

om the *.texi file. Have a nice day, Berny >From e93bdf684a7ed2c9229c0f113e33dc639f1050d7 Mon Sep 17 00:00:00 2001 From: Bernhard Voelker Date: Tue, 26 May 2020 23:16:44 +0200 Subject: [PATCH] doc/gnulib-intro.texi: add missing "to" in sentence Reported by Bjarni Ingi Gislason in &

Re: find, fts: dramatical improvement of speed in find

On 2020-04-23 19:24, Askar Safin wrote: > It seems you missed my letter. no. The point is that open source contribution is most often voluntary work - also at least in my case - which is done when there's time. And despite many people are bored due to Corona lock-down in many countries, for me

Re: find command trigger coredump

On 2020-04-16 21:36, Paul Eggert wrote: > On 4/16/20 9:32 AM, Bernhard Voelker wrote: > >> okay, strange - eventually I have time to try the same with du(1) later this >> evening. > > Yes, it is strange. I tried 'find' and the Gnulib patch fixed the bug for me >

Re: find command trigger coredump

On 2020-04-16 18:01, Paul Eggert wrote: > On 4/16/20 6:36 AM, Bernhard Voelker wrote: > >> I installed it in my local findutils tree, but find still crashes: > > Thanks for checking. Do you have a reproducer for that? The same as in the original post. https://lists.gnu.org/r/

Re: find command trigger coredump

On 2020-04-16 06:03, Paul Eggert wrote: > I worked around the bug by removing that optimization from Gnulib fts.c, by > installing the attached patch. I expect that this optimization is obsolete > nowadays, as XFS is now working and ReiserFS is either working, or is so > unpopular that high

[bug #57277] FAIL: test-canonicalize-lgpl with GCC 10

Update of bug #57277 (project findutils): Status:None => Fixed ___ Follow-up Comment #6: Thanks, Bruno. The attached picks up the gnulib patch by updating to latest. Pushed at:

[bug #57277] FAIL: test-canonicalize-lgpl with GCC 10

Update of bug #57277 (project findutils): Assigned to:None => berny ___ Reply to this item at: ___

[bug #57277] FAIL: test-canonicalize-lgpl with GCC 10

Follow-up Comment #1, bug #57277 (project findutils): First of all, the fix for this should go into gnulib --> adding their ML. Then, this test actually wants to verify the behavior of that function when called with a NULL value (it should return NULL and set errno to EINVAL). Therefore, the

Re: new modules for looking up the ancestors of a process

On 8/14/19 2:05 AM, Bruno Haible wrote: > diff --git a/modules/get_progname_of b/modules/get_progname_of > new file mode 100644 > index 000..012cc59 > --- /dev/null > +++ b/modules/get_progname_of > @@ -0,0 +1,24 @@ > +Description: > +Determine the program name of a given process. > + >

Re: [PATCH] pthread tests: fix missing-declarations warning.

On 7/22/19 12:39 PM, Bruno Haible wrote: > Thanks. Applied, [...] > Following your patch, I did the same thing in a couple of other files: Thanks for pushing. Have a nice day, Berny

[PATCH] pthread tests: fix missing-declarations warning.

): Declare static. --- ChangeLog | 10 ++ tests/test-pthread-cond.c | 2 +- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index 40d3e6741..14640d475 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,13 @@ +2019-07-22 Bernhard Voelker

Re: [PATCH] parse-datetime: avoid "%pure-parser" deprecation warning from Bison 3.4

Hi Bruno, On 7/20/19 12:57 AM, Bruno Haible wrote: > Hi Berny, > >>> 2019-07-19 Bruno Haible >>> >>> parse-datetime: Require Bison 2.7 or newer. > > Actually it requires Bison 2.4 or newer. good spot. >>> +case $ac_prog_version in >>> + '') ac_prog_version="v. ?.??, bad";

Re: [PATCH] parse-datetime: avoid "%pure-parser" deprecation warning from Bison 3.4

Hi Bruno, On 7/19/19 5:03 AM, Bruno Haible wrote: >> +parse-datetime: avoid "%pure-parser" deprecation warning from Bison 3.4 > > I've pushed your change. thanks. > However, I think it would be good for "make" to behave reasonably when bison > is not found or too old. > > Here's a

Re: maintainer-makefile: catch uses of $< in non-implicit rules

On 7/11/19 10:46 AM, Tim Rühsen wrote: > I can *NOT* reproduce the issue on Debian stretch (gawk 4.1.4, make 4.1). > Also, here the .deps/ directory is not being generated by make -qp. > > > Back to Debian unstable / Arch / Fedora 30. > > I tested with good old wget and see the same issue. > The

Re: maintainer-makefile: catch uses of $< in non-implicit rules

Hi Akim, On 5/18/19 11:51 AM, Akim Demaille wrote: > commit 2e801e81bb362429d0e252d076233bfdac20e367 > Author: Akim Demaille > Date: Sat May 18 08:46:00 2019 +0200 > > maintainer-makefile: catch uses of $< in non-implicit rules > > * top/maint.mk (sc_prohibit_magic_number_exit):

[PATCH] parse-datetime: avoid "%pure-parser" deprecation warning from Bison 3.4

2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index 08bcf1082..2f427010f 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2019-07-19 Bernhard Voelker + + parse-datetime: avoid "%pure-parser" deprecation warning from Bison 3.4 + * lib/

  1   2   >