Re: git-merge-changelog do not re-add ChangeLog entries

Hi Bruno, Bruno Haible via Gnulib discussion list writes: >> I most likely ran into the same problem you >> noticed.. so thanks for following through with a bug report. I'll see >> if I'm able to set it up and use it once this has been confirmed fixed. > > For yourself, I'd recommend to use the

Re: bug#79139: cp --reflink truncates sparse files on ZFS

Sam James writes: > if that is ever useful. The changes themselves look good. Really, c_f_r > has been an API plagued with problems :( To be fair this is not the fault of copy_file_range itself. Not that it makes the situation any better. :) Collin

Re: bug#79139: cp --reflink truncates sparse files on ZFS

ne with the attached patch now. > Collin Funk wrote: >> Can't we make this condition only occur for glibc 2.41 and glibc 2.42? >> The issue shouldn't occur before commit >> 89b53077d2a58f00e7debdfe58afabe953dac60d in glibc (2024-06-25). > > Users are supposed to be

Re: bug#79139: cp --reflink truncates sparse files on ZFS

Paul Eggert writes: > On 2025-08-01 15:05, Collin Funk wrote: >> I was hoping that file could be made a tiny stub, due to the >> workarounds for Linux 4.19 being mostly unnecessary now that it is EOL. >> But now we have a new problem to deal with. :) > > That we do

Re: nproc honoring cgroup limits

Bruno Haible via Gnulib discussion list writes: >> The cgroup constraint would be inferred from: >>cat $(findmnt -n -t cgroup2 -o target)/$(cut -d: -f3- < >> /proc/self/cgroup)/cpu.max > > On my system, that file does not exist: That command didn't work for me. But I can use this: $ po

Re: nproc honoring cgroup limits

Hi Pádraig, Pádraig Brady writes: > cgroup constraints are a popular mechanism on linux. > I was thinking of augmenting the nproc routines > to incorporate cgroup cpu constraints for NPROC_CURRENT_OVERRIDABLE > so that we'd return MIN(cgroup constraint, current value); > > The cgroup constraint

Re: nstrftime: Handle non-Gregorian calendars the same way on all platforms

Hi Bruno, Patch looks good, thanks! Bruno Haible via Gnulib discussion list writes: > Collin: With this patch, the three coreutils tests now fail on OpenBSD the > same > way as they fail on macOS > . > This means, you can use gdb on OpenBSD

Re: announce-gen: Add support for dist-zip.

Collin Funk writes: > I noticed that gzip distributes .zip archive releases, but your > announcement messages do not mention them [1]. Is there any reason not > to? > > If not, I can push the attached patch. It is a simple one line change. I pushed the attached patch instead. It

export VAR=VAL portability

Hi Bruno, While reviewing your Coreutils 'date' patch, I skimmed some of the linked gettext manual. I noticed this text [1]: At the shell prompt, merely execute ‘setenv LANG de_DE’ (in csh), ‘export LANG; LANG=de_DE’ (in sh) or ‘export LANG=de_DE’ (in bash). I had assumed the sh/bash dis

Re: git-merge-changelog do not re-add ChangeLog entries

Patrice Dumas writes: > On Thu, Jul 24, 2025 at 10:15:40AM +0200, Bruno Haible wrote: >> * What if you build git-merge-changelog yourself (using the build >> instructions >> at the top of gnulib/lib/git-merge-changelog.c), instead of relying on the >> build from your distro? > > I tried an

posixtm tests: Avoid test failure on Haiku.

to disable them. Collin >From 114d91d7c3c829290eca4ef4701a22397aa04223 Mon Sep 17 00:00:00 2001 Message-ID: <114d91d7c3c829290eca4ef4701a22397aa04223.1753329333.git.collin.fu...@gmail.com> From: Collin Funk Date: Wed, 23 Jul 2025 20:54:50 -0700 Subject: [PATCH] posixtm tests: Avoid te

sethostname tests: Avoid test failure on Haiku.

large hostnames, I reported it to the Haiku tracker [1]. Collin [1] https://dev.haiku-os.org/ticket/19692 >From e936bfd8c0aad5eba0b6dfc7586d1b512bd90c26 Mon Sep 17 00:00:00 2001 Message-ID: From: Collin Funk Date: Wed, 23 Jul 2025 19:55:41 -0700 Subject: [PATCH] sethostname tests: Avoid test fa

Re: thrd: Fix -Wincompatible-pointer-types on AIX 7.3.

Bruno Haible writes: > Yep, this patch would fix the compilation error, but would still have > undefined behaviour (and the clang UBSAN actually crashes upon function > pointer type conversion). > > I'm committing this patch instead. It's a little more ugly, but no undefined > behaviour. Tested o

Re: doc: Document that fsync doesn't work on directories on AIX 7.3.

Paul Eggert writes: > On 2025-07-22 14:47, Collin Funk wrote: >>int fd = open (".", O_DIRECTORY); > > I think one also needs O_RDONLY for that to conform to POSIX. Oops, you are right. POSIX says it needs one of O_EXEC, O_RDONLY, O_RDWR, O_SEARCH, or O_WRONLY.

doc: Document that fsync doesn't work on directories on AIX 7.3.

373 Mon Sep 17 00:00:00 2001 Message-ID: <7075f2377516eef250d2409307219bb80de3d373.1753220605.git.collin.fu...@gmail.com> From: Collin Funk Date: Tue, 22 Jul 2025 14:40:50 -0700 Subject: [PATCH] doc: Document that fsync doesn't work on directories on AIX 7.3. Reported by Lakshmi-Surekha in: <https://github.com/t

thrd: Fix -Wincompatible-pointer-types on AIX 7.3.

ached patch to fix it? Maybe you can think of a cleaner way to do it without the function cast. Collin >From 47cbc846b6b082ce5741fda20690a04f47c2e098 Mon Sep 17 00:00:00 2001 Message-ID: <47cbc846b6b082ce5741fda20690a04f47c2e098.1753212997.git.collin.fu...@gmail.com> From: Collin Funk

sys_un-h: Make sure that the 'sys' subdirectory is created.

e for 'sys/un.h' executes faster than the others. Fixed with the attached patch. Collin >From f07c45598e16a06aa9766b8cb45a9fc4448fac07 Mon Sep 17 00:00:00 2001 Message-ID: From: Collin Funk Date: Mon, 21 Jul 2025 19:04:09 -0700 Subject: [PATCH] sys_un-h: Make sure that the 'sys&

Re: stdioext: Port to recent OpenBSD snapshots with an incomplete FILE type.

ld you please use "|" or "," instead? Upon a second look I am not really sure why I wrote it that way, since the rest of the comments are split with a comma. It looks quite strange. Fixed with the attached, thanks. Collin >From dd8fae4b6fbf2474cd4f3b50cbc8da54a41fce9f Mo

stdioext: Port to recent OpenBSD snapshots with an incomplete FILE type.

Collin Funk writes: >> Do you want to deal with it, or should I ? > > I'll take a look later today. I pushed the attached patch which fixes it. It is much simpler than I expected since most of the Android code can be reused for OpenBSD. I know Bionic uses a lot of BSD stuff,

Re: FILE is now an incomplete type on OpenBSD.

Bruno Haible writes: > It looks like nightly or weekly builds of OpenBSD are available from > https://cdn.openbsd.org/pub/OpenBSD/snapshots/amd64/ . Ah, cool! I was not aware. I thought we would have to wait for a release or build it ourselves. > Do you want to deal with it, or should I ? I'll

FILE is now an incomplete type on OpenBSD.

Hi Bruno, I just saw this change in OpenBSD making FILE an incomplete type [1]. GitHub mirror since I do not know CVS very well [2]. I assume that this change will require some changes to the stdio_ext.h functions along with some others maybe like fflush. Therefore, I figured it was worth mention

Re: commit signing

Bruno Haible via Gnulib discussion list writes: > Why should we mention this? The Gnulib repository doesn't use signed commits. > > And IMO it doesn't need to. Last time we discussed this, IIRC Simon noted > that enforcing signed commits hampers development by causing hassles to > the developers.

announce-gen: Add support for dist-zip.

>From 84c568dc9533319bad5227686976ceebf942651b Mon Sep 17 00:00:00 2001 Message-ID: <84c568dc9533319bad5227686976ceebf942651b.1752984002.git.collin.fu...@gmail.com> From: Collin Funk Date: Sat, 19 Jul 2025 20:50:43 -0700 Subject: [PATCH] announce-gen: Add support for dist-zip. *

Re: README-release and Hydra

Bruno Haible writes: > Collin Funk wrote: >> [3] https://cgit.git.savannah.gnu.org/cgit/hydra-recipes.git > > The coreutils recipe is unmaintained since 2018, and the gettext > recipe since 2015. > > I think it's safe to remove that paragraph. Thanks for confirming.

README-release and Hydra

Hi, In the README-release file there is the following section: * Check that the NixOS/Hydra autobuilder is reporting all is well: https://hydra.nixos.org/project/gnu/@PACKAGE@-master However, it seems these builds have not successfully run since 2020-2021 [1]. We can see some fa

Re: epsf.tex: New file

Hi Bruno, Bruno Haible via Gnulib discussion list writes: > Having said that, I would be in favour of retiring the DVI format from > the GNU Coding Standards. The DVI format was commonplace in the 1990ies, > but lost popularity to the PDF format starting 2008 (when PDF became an > open standard)

Re: doc: Mention copy_file_range stub on GNU/Hurd.

Collin Funk writes: > When linking a program that uses copy_file_range on GNU/Hurd you will > see the following warning: > > gcc -std=gnu23 -Wno-error -g -O2 -o test-copy-file test-copy-file.o > libtests.a ../gllib/libgnu.a libtests.a ../gllib/libgnu.a libtests.a -lacl

Re: nstrftime: Add support for non-Gregorian calendars

Bruno Haible writes: >> OK, I will propose a coreutils 'date' documentation patch that explains >> the caveats with non-Gregorian calendars. > > Done, to the coreutils mailing list. Interesting, I can see it on the archive. But I did not receive the mail despite being subscribed. I guess I will

doc: Use @code around errno constants.

tml >From 17357997e9ed29453b0fea484e646dd0cdace14c Mon Sep 17 00:00:00 2001 Message-ID: <17357997e9ed29453b0fea484e646dd0cdace14c.1752710917.git.collin.fu...@gmail.com> From: Collin Funk Date: Wed, 16 Jul 2025 16:57:06 -0700 Subject: [PATCH] doc: Use @code around errno constants.

Re: nstrftime: Add support for non-Gregorian calendars

Bruno Haible writes: >> As you mentioned, in Thailand the Gregorian calendar is used alongside >> the Thai solar calendar (even if it is used less so in day-to-day life). > > Yes, what does *not* matter, IMO, for the 'date' program is use in > religious life (as opposed to official and everyday c

doc: Mention copy_file_range stub on GNU/Hurd.

p 17 00:00:00 2001 Message-ID: <07610f0dbe3d209206918af76dea6d1e061e4425.1752635988.git.collin.fu...@gmail.com> From: Collin Funk Date: Tue, 15 Jul 2025 20:16:46 -0700 Subject: [PATCH] doc: Mention copy_file_range stub on GNU/Hurd. * doc/glibc-functions/copy_file_range.texi: Use @code around

Re: nstrftime: Add support for non-Gregorian calendars

Hi Bruno, Bruno Haible via Gnulib discussion list writes: > This patch adds proper support for the non-Gregorian calendars in use in > - Thailand, > - Iran, > - Ethiopia, > to the 'nstrftime' module and, with it (automatically) to the GNU coreutils > 'date' program (for output). > > Why is

Re: nstrftime: Add support for non-Gregorian calendars

Pádraig Brady writes: >> I'm not sure what you mean. >> I checked the conversions for consistency with what ICU does, and >> except for one difference [1] it seems to be consistent. But I don't >> think you would like to make use of ICU in the "make check" target of >> coreutils? >> Or do you mea

*_t namespace

Marc Nieper-Wißkirchen writes: > (*) Unfortunately, they often use the POSIX-reserved "_t" namespace, > but that's a different issue. I used to feel the same way, but other namespaces for types end up being ugly. For example, I think vim uses "*_T". It is unlikely that POSIX will standardize na

Re: THANKS files and email addresses?

Hi Simon, Simon Josefsson via Gnulib discussion list writes: > My impression is that even maintaining an accurate list of contributors > to thank in a THANKS file is not particular useful any more. The git > log is a more accurate source of who did what (and consequently should > be thanked), p

Re: THANKS files and email addresses?

ls should probably be kept, since a name alone isn't enough to identify someone. For example, there are many "Collin Funk"'s alive today, but only I use . Similarly, if my I leave my current employer and a THANKS file happens to use that email, it would identify me as a c

Re: Many Gnulib errors on Cygwin trying to build Bison from source

Paul Eggert writes: > I'm not quite following all those bug reports. When you say "build > Bison from source", do you mean "build from the latest release > tarball", or "build from Git"? I suspect you mean the latter, but if > so you'll likely have more hassle. Why is the latter needed? > > As fa

Re: [PATCH] Update RE_SYNTAX_EMACS to include features used by GNU Emacs

Bernhard Voelker writes: > 2. Commit (to be pushed) to gnulib - see attachment. > > Good to push? That patch looks good, thanks. I confirmed that I receive the same output when running './regexprops "Regular Expressions" generic'. I'll send you a patch later to fix 'make syntax-check' after the

Re: [PATCH] Update RE_SYNTAX_EMACS to include features used by GNU Emacs

Hi Paul, Trimming CC and adding Bernhard and bug-findut...@gnu.org in case anyone else wants to add input. Paul Eggert writes: > Thanks; I installed the attached somewhat fancier patch into Gnulib. > > From efd5c380ff8062541d5fd98b050ecd3cb295917c Mon Sep 17 00:00:00 2001 > From: Paul Eggert >

stdcountof-h: Add reminder to include .

since lib/gnulib-common.m4 will emit a _GL_GNUC_PREREQ definition in config.h. We must include it before these headers so it is defined. Done with the two attached patches. Collin >From adad3d69237190d12ad15abb077ed8ff6eb0ca3b Mon Sep 17 00:00:00 2001 Message-ID: From: Collin Funk Date: Tue,

Re: vasnprintf: Silence -Wswitch-unreachable warning.

Bruno Haible writes: > Yes, I saw this warning too, on some platforms. But warnings on non-GNU > platforms don't bother me enough. Yep, I think it is nice to silence warnings enabled by default. But no need to spend a ton of time on it. >> Any objections to the attached patch? > > I prefer to c

vasnprintf: Silence -Wswitch-unreachable warning.

ad88fc0363fb2475646a150 Mon Sep 17 00:00:00 2001 Message-ID: <6f21a61a6458de619ad88fc0363fb2475646a150.1751835887.git.collin.fu...@gmail.com> From: Collin Funk Date: Sun, 6 Jul 2025 13:48:53 -0700 Subject: [PATCH] vasnprintf: Silence -Wswitch-unreachable warning. * lib/vasnprintf.c (VASNPRI

Re: pagealign_alloc: Don't assume pointers fit in 'unsigned long'.

t familiar with them. Perhaps I will get around to reading the manual at some point [1]. Collin [1] https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-947.pdf >From a5c7974191230a73c67926cb38d8539d9252f942 Mon Sep 17 00:00:00 2001 Message-ID: From: Collin Funk Date: Sun, 6 Jul 2025 10:07:3

Re: strptime: Convert K&R definitions to ANSI C.

Bruno Haible writes: > Thanks. Good to see that it is consistent with glibc > commit 80d9be8122d1fe181d2476b5dad9f4ce37204958 (so as to avoid > gratuitous divergence). Yep, I changed the LOCALE_PARAM definition under _LIBC even though it isn't relevant to Gnulib because I hope it makes it easier

pagealign_alloc: Don't assume pointers fit in 'unsigned long'.

Memo#Summary >From 47f10829e58409e955eef40a681b1f9fd9dd423e Mon Sep 17 00:00:00 2001 Message-ID: <47f10829e58409e955eef40a681b1f9fd9dd423e.1751772648.git.collin.fu...@gmail.com> From: Collin Funk Date: Sat, 5 Jul 2025 20:09:11 -0700 Subject: [PATCH] pagealign_alloc: Don't assume pointers fit in 

strptime: Convert K&R definitions to ANSI C.

Collin >From 2de660857831ef886138312ec6276382cc97207f Mon Sep 17 00:00:00 2001 Message-ID: <2de660857831ef886138312ec6276382cc97207f.1751769365.git.collin.fu...@gmail.com> From: Collin Funk Date: Sat, 5 Jul 2025 19:34:51 -0700 Subject: [PATCH] strptime: Convert K&R definitions to ANSI

Re: [PATCH] listxattr: document Linux 6.15 bug

Pádraig Brady writes: > Excellent. I updated the bug with that info: > https://bugzilla.redhat.com/2369561 Thanks! I forgot that I should do that... > The issue wasn't in the wild long enough really so > to warrant any more workarounds. Agreed. Collin

Re: [PATCH] listxattr: document Linux 6.15 bug

Pádraig Brady writes: > Various gnulib acl tests breaking (on fedora 42 for example) is problematic. > > For my ref one can work around the issue by pointing TMPDIR away from tmpfs > like: > > TMPDIR=/foo/bar make check > > I was considering skipping the tests if on tmpfs with kernel 6.1[45],

Re: strcasecmp_l: Fix missing declaration of c_strcasecmp (regr. 2025-02-16).

when the lib/strcasecmp_l.c was first added. Yep, I was typing habitually and clearly did not think about the definition of "regression". :) Fixed with the attached patches. Collin >From bbb058b782d1ba5850924084ac4957e198ccf57d Mon Sep 17 00:00:00 2001 Message-ID: From: Collin Funk D

Re: strcasecmp_l: Fix missing declaration of c_strcasecmp (regr. 2025-02-16).

Collin Funk writes: > This is a warning on the CI because of the GCC version it uses. But it > becomes an error in GCC 14 [1]. Forgot to mention, you can see the warning on MinGW 64-bit CI runner. Collin

strcasecmp_l: Fix missing declaration of c_strcasecmp (regr. 2025-02-16).

.1751683475.git.collin.fu...@gmail.com> From: Collin Funk Date: Fri, 4 Jul 2025 19:34:06 -0700 Subject: [PATCH 1/2] strcasecmp_l: Fix missing declaration of c_strcasecmp (regr. 2025-02-16). * lib/strcasecmp_l.c [GNULIB_defined_locale_t]: Include c-strcase.h. --- ChangeLog | 3 +++ lib/

forkpty: Adjust misleading comment.

3e18d6ecffbe3a53f626547 Mon Sep 17 00:00:00 2001 Message-ID: <723a56c3d3ce49c303e18d6ecffbe3a53f626547.1751679389.git.collin.fu...@gmail.com> From: Collin Funk Date: Fri, 4 Jul 2025 18:33:08 -0700 Subject: [PATCH] forkpty: Adjust misleading comment. * lib/forkpty.c: Remove comment about

Re: [musl] Re: BUG: realloc(p,0) should be consistent with malloc(0)

Alejandro Colomar writes: > BTW, I was trying to find out the history of memccpy(3), and why it was > introduced in 4.4BSD. Does anyone know the history? I find it a weird > function that doesn't have any good use case, or I don't seem to see it. > Every use case I see, such as a poor-man's str

Re: gnupload: Remove checks for gpg2.

2a525fb82bc276d74e4c91978.1751137817.git.collin.fu...@gmail.com> From: Collin Funk Date: Sat, 28 Jun 2025 12:04:50 -0700 Subject: [PATCH] gnupload: adjust commentary regarding gnupg versions Suggested by Bruno Haible in: <https://lists.gnu.org/archive/html/bug-gnulib/2025-06/msg00310.html

gnupload: Remove checks for gpg2.

lt;9a35ac361330b9058b475d0db0906f2e458f2012.1751134349.git.collin.fu...@gmail.com> From: Collin Funk Date: Sat, 28 Jun 2025 10:56:56 -0700 Subject: [PATCH] gnupload: Remove checks for gpg2. * build-aux/gnupload (GPG): Remove checks for gpg2 and use gpg unconditionally. --- ChangeLog | 6 +

Re: getopt_long API

Ben Pfaff writes: >> I propose to add to getopt_long() — in Gnulib — code that verifies >> the consistency between the two places, when a certain environment >> variable (say, GETOPT_DEBUG) is set. And produces output on stderr >> such as: >> getopt_long: warning: option '--context' requires an

Re: getopt_long API

Hi Bruno, Bruno Haible via Gnulib discussion list writes: > The problem is that the properties of an option have to be specified > in *two* places: in the long_options array *and* in the 3rd argument > to getopt_long(). > > I propose to add to getopt_long() — in Gnulib — code that verifies > the

Re: string-desc: Fix a compiler warning

Hi Bruno, Bruno Haible via Gnulib discussion list writes: > The AIX xlc compiler gives this warning: > > "../../../gettext-tools/gnulib-lib/string-desc.h", line 674.24: 1506-1332 (W) > A function with return type "void" may not return a value of type "void". > > Fixed like this: Do gcc and cla

Re: return void

Bruno Haible writes: >> Do gcc and clang not warn about this? > > With option '-pedantic', they warn, yes: > > $ cat foo.c > extern void foobar (int); > void foo (int x) { return foobar (x); } > > $ gcc -Wall -S -pedantic foo.c > foo.c: In function ‘foo’: > foo.c:2:27: warning: ISO C forbids ‘ret

Re: malloc.3: Clarify realloc(3) standards conformance

Alejandro Colomar writes: > BTW, Paul, Bruno, does gnulib also wrap reallocarray(3)? If not, it > should. Yep, Gnulib has had it since 2017 after it was added to glibc. Collin signature.asc Description: PGP signature

Re: [PATCH] fs/xattr.c: fix simple_xattr_list()

Christian Brauner writes: >> Checking on the status of this patch as we are at -rc2 and I don't see >> it in Linus' tree? > > Sent this morning with some other fixes. I see it merged now [1]. Thanks for the help all. Collin [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.g

Re: fenv-env tests do not compile on sh4

Hi Bruno, Bruno Haible writes: > Fixed through this patch: > > > 2025-06-15 Bruno Haible > > fenv-environment tests: Fix compilation errors on Linux/sh4. > Reported by Collin Funk in > <https://lists.gnu.org/archive/html/bug-gnulib/2025-06/msg0

Re: fenv-env tests do not compile on sh4

Collin Funk writes: > Should these tests do something like this? > > /* Modify the current environment. */ > #if !defined __sh__ > #define ENV1_ROUNDING_DIRECTION FE_TONEAREST > #define ENV2_ROUNDING_DIRECTION FE_TOWARDZERO > #else > #define

fenv-env tests do not compile on sh4

Hi Bruno, I found that the fenv-env tests do not compile on sh4. This is the error: test-fenv-env-2.c: In function 'main': test-fenv-env-2.c:49:15: error: 'FE_UPWARD' undeclared (first use in this function) 49 | fesetround (FE_UPWARD); | ^ tes

NUL and /dev/null

Hi Bruno, Unrelated to the original patch, but something I noticed... Bruno Haible via Gnulib discussion list writes: > +#if defined _WIN32 && !defined __CYGWIN__ > +fd = open ("NUL", O_RDWR); > +#else > +fd = open ("/dev/null", O_RDWR); > +#endif Perhaps it is worth adding a macro for

Re: dcomp-script: Reject D compilers with installation problems

Bruno Haible writes: > Collin Funk wrote: >> But it would be nice to report it if it is a bug. > > Done: https://cygwin.com/pipermail/cygwin/2025-June/258291.html Thanks! Collin

Re: dcomp-script: Reject D compilers with installation problems

Hi Bruno, Bruno Haible via Gnulib discussion list writes: > On Cygwin, the GNU D compiler (gdc) is installed without its standard > library. As a consequence, it cannot compile anything. This leads to build > errors later in GNU gettext. > > It is better if the configure test catches this situat

Re: MinGW-w64 fenv changes.

Hi Bruno, Bruno Haible writes: > Collin Funk wrote: >> But, I think most of my issues came from trying to implement 'fegetenv' >> and 'fesetenv'. > > Well, you started with the wrong module. Because the module > 'fenv-environment' depends on

Re: parse-datetime bug on NetBSD 10.0

Hi Paul, Paul Eggert writes: > Yes, this is an iffy area in the mktime spec. I installed the attached > further coreutils patch to try to avoid the iffy area. Thanks, the test passes with that patch. I guess non-existent times due to daylight savings were probably an after thought when writing

Re: parse-datetime bug on NetBSD 10.0

Hi Paul, Paul Eggert writes: > On 2025-06-08 17:39, Collin Funk wrote: >> Posting on bug-gnulib since this test failure seems to be caused by >> parse-datetime despite being caught by tests/date/date-debug.sh in >> Coreutils. > > I installed the attached patch to

Silence 'time-stamp' warnings with bleeding-edge Emacs.

p 17 00:00:00 2001 Message-ID: <9a1a6385a57bd6c6493ba1d0660a960574953a9a.1749523932.git.collin.fu...@gmail.com> From: Collin Funk Date: Mon, 9 Jun 2025 19:50:35 -0700 Subject: [PATCH] Silence 'time-stamp' warnings with bleeding-edge Emacs. * build-aux/announce-gen: Use "%Y"

Re: MinGW-w64 fenv changes.

Hi Bruno, Bruno Haible writes: > On the GitHub CI machines, I now see compilation failures on mingw: > [...] > This means that the mingw people made a release with that change included, > and it is active in the GitHub CI environments. > > I want to get this fixed ASAP, but I don't want to dupli

Re: parse-datetime bug on NetBSD 10.0

Bruno Haible writes: >> Posting on bug-gnulib since this test failure seems to be caused by >> parse-datetime despite being caught by tests/date/date-debug.sh in >> Coreutils. >> >> On NetBSD 10.0 (cfarm428.cfarm.net) it fails with the following: > > This is a NetBSD 10.0/arm64 machine. What abo

parse-datetime bug on NetBSD 10.0

Hi, Posting on bug-gnulib since this test failure seems to be caused by parse-datetime despite being caught by tests/date/date-debug.sh in Coreutils. On NetBSD 10.0 (cfarm428.cfarm.net) it fails with the following: + returns_ 1 date --debug -d 'TZ="America/Edmonton" 2006-04-02 02:30:00'

Re: OpenPGP keys

Hi Bruno and Simon, Reviving this very old thread because looking at maintain.texi reminded me of it. It says: Optional but recommended: Send your keys to a GPG public key server: @code{gpg --keyserver keys.gnupg.net --send-keys @var{keyid}...}, where @var{keyid} is the eight hex digi

doc: Add some missing Makefile targets.

l/bug-standards/2025-06/msg0.html >From 9a604394f3b820ccb2294e8ba65bb9b9baa355de Mon Sep 17 00:00:00 2001 Message-ID: <9a604394f3b820ccb2294e8ba65bb9b9baa355de.1749268368.git.collin.fu...@gmail.com> From: Collin Funk Date: Fri, 6 Jun 2025 20:52:07 -0700 Subject: [PATCH] doc: Add some mi

Re: Recent Linux kernel commit breaks Gnulib test suite.

Hi Paul, [Dropping all except bug-gnulib from CC] Paul Eggert writes: > I saw that bug last month, and filed a Fedora bug report here: > > https://bugzilla.redhat.com/show_bug.cgi?id=2369561 > > The kernel bug breaks libxattr's attr_copy_fd and attr_copy_file > functions, among other things. T

Re: [PATCH] fs/xattr.c: fix simple_xattr_list()

gth of the >> > returned xattr name. This results in simple_xattr_list() incorrectly >> > returning this length even if a POSIX acl is also set on the inode. >> > >> > Reported-by: Collin Funk >> > Closes: https://lore.kernel.org/selinux/8734ceal7q@gmail.com

Recent Linux kernel commit breaks Gnulib test suite.

Hi, Using the following testdir: $ git clone https://git.savannah.gnu.org/git/gnulib.git && cd gnulib $ ./gnulib-tool --create-testdir --dir testdir1 --single-configure `./gnulib-tool --list | grep acl` I see the following result: $ cd testdir1 && ./configure && make check [...

Re: a country name change

Bruno Haible writes: >> $ grep -rie 'yugoslav' >> lib/setlocale_null.h: ("FYRO Macedonian_Former Yugoslav Republic of >> Macedonia.1251"). */ >> lib/setlocale.c: MKI FYRO Macedonian_Former Yugoslav Republic of >> Macedonia.1251 >> lib/setlocale.c:{ "MK", "Former Yugo

setlocale: Update a comment.

ibc-alpha/bd1c3df2b8aaaeaf6199e715212db67d2b80266f.1748980203.git.collin.fu...@gmail.com/T/#u >From 61c4a6ae9ebdbabdfdcc0175b6f467419bada300 Mon Sep 17 00:00:00 2001 Message-ID: <61c4a6ae9ebdbabdfdcc0175b6f467419bada300.1748980594.git.collin.fu...@gmail.com> From: Collin Funk Date:

Re: _Countof operator and countof macro (C2y)

Hi all, Bruno Haible via Gnulib discussion list writes: >> > BTW, do you have in plans for using this module within gnulib itself? > > Sure. I'll just wait a week or so > - to give other people a chance to chime in, > - to wait for the weekly CI results. Alejandro, I did not read all the do

Re: move kwset to gnulib?

Bruno Haible writes: > Collin Funk wrote: >> You already probably thought about this, but just to be sure. In >> kwset.[ch]: >> >> /* Written August 1989 by Mike Haertel. */ >> >> Is it okay to move it to Gnulib since Grep is assigned to the FSF?

Re: move kwset to gnulib?

Bruno Haible via Gnulib discussion list writes: > The files kwset.[ch] from GNU grep are also used in GNU gettext > (and some other non-GNU packages, e.g. 'git'). > > Paul, Jim: Would it be OK to move them to a Gnulib module? > > I would like to eliminate future updates of this code from the gett

Re: Fixes for compilation failures with -Werror=format-security and disabled nls

Bruno Haible writes: > Thanks for the report. The relevant gcc option here is '-Wextra'. > Fixed through the patch below. > >> I think I remember you mentioning that gettext will be standardized to >> return 'const char *' in the future. If so, I expect glibc and others to >> change this in the f

Re: Fixes for compilation failures with -Werror=format-security and disabled nls

Hi Bruno, Bruno Haible via Gnulib discussion list writes: > /usr/include/libintl.h:54:14: note: previous declaration of ‘dcgettext’ with > type ‘char *(const char *, const char *, int)’ >54 | extern char *dcgettext(const char *, const char *, int); > | ^ > *** Err

Re: Fixes for compilation failures with -Werror=format-security and disabled nls

Hi Bruno, Bruno Haible writes: > Collin Funk wrote: >> The issue is that __attribute__ ((__format (...))) adds a check to make >> the format string is actually a string. When it sees a call to 'gettext' >> it assumes that it can return NULL which will cause issues

Re: vasnprintf: Fix uninitialized values.

Bruno Haible writes: > It was introduced in commit 7d8705539af0c8555badacbdbe9c92ae0abca6f5. > Probably I thought that the uninitialized value doesn't matter, since in this > line it gets multiplied by 0, and 0 * anything is 0. But valgrind reports > an "uninitialised value" in such a case. There

vasnprintf: Fix uninitialized values.

ys do "p += intpart_digits + insert * thousep_len" unconditionally without an early return. Can you confirm the attached patch is correct? Since this was introduced by your grouping fixes ~2 months ago. Collin >From 27045298b98c7fd07c848326af3556971c48d264 Mon Sep 17 00:00:00 2001

Re: [PATCH 3/3] fcntl-h: document O_CLOFORK etc

Hi Bruno and Paul, Bruno Haible via Gnulib discussion list writes: >> +Although POSIX.1-2024 standardized @code{O_CLOFORK}, >> +@code{FD_CLOFORK} and @code{F_DUPFD_CLOFORK}, >> +they are not defined on most platforms: >> +glibc 2.41, musl libc, macOS 15.5, FreeBSD 14.2, NetBSD 10.1, OpenBSD 7.7,

Re: crypto/gc: Pacify -Wformat warnings.

s (such as converting from a pointer type > or truncating some bits) that here I would prefer a code without a cast. I agree, it is best to avoid casts. I pushed the attached patch with your suggestion. Collin >From a90d0ae6c84f3496d247d251194fc3eab150304e Mon Sep 17 00:00:00 2001 Message-ID

crypto/gc: Pacify -Wformat warnings.

f94 Mon Sep 17 00:00:00 2001 Message-ID: From: Collin Funk Date: Mon, 26 May 2025 11:27:34 -0700 Subject: [PATCH] crypto/gc: Pacify -Wformat warnings. * lib/gc-gnulib.c (gc_cipher_setkey, gc_cipher_setiv): Cast the argument since "%02x" expects the argument to be unsigned. --- ChangeLo

Re: selinux-h: Fix error with MSVC

Bruno Haible writes: > Maybe it's more useful to randomize things? Each week, pick a different set > of 10 modules, create a megatestdir of these modules and build & check it in > the 20 platforms/environments that the CI supports? That would probably work well. Collin

Re: selinux-h: Fix error with MSVC

Bruno Haible writes: >> Wouldn't the following do the same? >> >> $ gnulib-tool --create-megatestdir --dir testdir1 $(gnulib-tool --list | >> grep -- '-h$') > > That's what I did, yes: > $ ./gnulib-tool --create-megatestdir --dir testdir1 --single-configure > --with-c++-tests `cd modules

Re: selinux-h: Fix error with MSVC

Hi Bruno, Bruno Haible via Gnulib discussion list writes: > Building a testdir of 'selinux-h' on MSVC, I get these errors: > > .\selinux/selinux.h(87): error C2059: syntax error: ',' > .\selinux/selinux.h(87): error C2059: syntax error: ';' > .\selinux/selinux.h(87): error C2061: syntax error: i

Re: stdckdint-h: Work around missing declarations with g++ 15.0.

eporting one or the other as a "bug". Okay, makes sense. I agree, not a bug. I just wasn't sure that it was intentional at the time. Anyways, pushed the attached patch since the changes were minimal. Thanks for checking! Collin >From e331531a771443edae4135e6bcd016282cf1a3aa Mon

Re: Fixes for compilation failures with -Werror=format-security and disabled nls

Hi Bruno and Holger, Bruno Haible via Gnulib discussion list writes: > Thanks. Yes, it is useful: > - The size of your patch makes it clear that this is not the way to go. > - The mention that it is specific to --disable-nls makes it clear that > we need to look for a workaround in gette

Re: stdckdint-h: Work around missing declarations with g++ 15.0.

cond case, when compiling a C program simply does an #include_next. Collin (*) I find it strange that the C++ declarations are hidden depending on the C++ standard, but the C ones are not. I would expect -std=(gnu|c)99 to disable them like the C++ version. >From 97dbb1f1a349c4817e91ed2b5fcc5c30b

Re: stdckdint-h: Work around missing declarations with g++ 15.0.

Bruno Haible via Gnulib discussion list writes: > Paul Eggert wrote: >> As the stdckdint.h bug in question is fixed in GCC 15.1, wouldn't it be >> better if the Gnulib workaround is used only if the bug is present (GCC >> 15.0)? > > Who said that is was fixed in GCC 15.1 ? I reproduce it with g

Re: stdckdint-h: Work around missing declarations with g++ 15.0.

Paul Eggert writes: > That's fine, but Gnulib does have a portable way to see whether the > C++ compiler works properly with . Namely, compile a > little test with the C++ compiler and if that compiles > OK, do not generate stdckdint.h. > > In general we're better off if we don't second-guess a

  1   2   3   4   5   6   7   8   9   10   >