bug#62385: POSIX behavior of readlink, realpath

On 2025-08-03 12:47, Collin Funk wrote: How about the wording and formatting of the attatched patch? Thanks, looks good.

bug#62385: POSIX behavior of readlink, realpath

On 2025-08-03 11:08, Collin Funk wrote: + readlink will behave as if the -v option is used if the + POSIXLY_CORRECT environment variable is defined. This isn't true if -q/--quiet/-s/--silent is specified. I would reword this to something like "readlink now defaults to being verbose if POSI

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

rnels (which is dubious if you ask me) aren't building for older glibcs (which is even more dubious).From a44c85a227c84542cc5849b976eaccdd61d44354 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 2 Aug 2025 08:52:29 -0700 Subject: [PATCH] More copy_file_range commentary ---

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

On 2025-08-01 20:56, Collin Funk wrote: Also, I assume this bug will cause problems in any syscall returning ssize_t (e.g. read, write, send). It could well do that, yes. I suspect I haven't run into it because the programs I help maintain respect SYS_BUFSIZE_MAX in their calls to those other

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

ng it. That one was quite a whopper.From 626f229915b114731cc4c9d9bda9eaa82d58180b Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 1 Aug 2025 14:46:51 -0700 Subject: [PATCH 1/2] copy-file-range: tune for more-modern kernels MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Tra

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

On 2025-08-01 14:40, Pádraig Brady wrote: Could you log this with https://sourceware.org/bugzilla/ He already did that, here: https://sourceware.org/bugzilla/show_bug.cgi?id=33245 I should have a Gnulib fix shortly.

bug#79130: Change/feature requests chcon/chgrp/chmod/chown/touch

On 2025-07-30 01:05, Martin D Kealey wrote: I would like the 'chown -h' and 'chcon -h' to work the same way as 'touch -h': as well as not following symlinks for targets, they should also not follow a symlink given as --reference=. Makes sense to me. Let's see what others think. If the patch is

bug#47243: pr lacks -p

On 2025-07-29 21:51, Collin Funk wrote: + /* Just exit if the user presses Ctrl-D. */ + if (bytes_read == 0) +return; This needs reworking now that 'pause_maybe' is a separate function, as the code no longer exits, it just keeps going. One other thought. It ma

bug#47243: pr lacks -p

On 2025-07-30 11:29, Pádraig Brady wrote: On 30/07/2025 18:31, Paul Eggert wrote: On 2025-07-30 04:18, Pádraig Brady wrote: I'd have a slight preference for _not_ gating the isatty(STDOUT) check on $POSIXLY_CORRECT. We generally only use $POSIXLY_CORRECT to gate incompatible behavior.

bug#47243: pr lacks -p

On 2025-07-30 04:18, Pádraig Brady wrote: I'd have a slight preference for _not_ gating the isatty(STDOUT) check on $POSIXLY_CORRECT. We generally only use $POSIXLY_CORRECT to gate incompatible behavior. Sure, but don't the GNU coding standards disagree with POSIX here? If we follow the GNU c

bug#47243: pr lacks -p

On 2025-07-29 10:11, Collin Funk wrote: And that wasn't the worst device I used to write programs! I'm curious, what is the worst? The IBM 029 card punch, introduced in 1964, was worse. https://en.wikipedia.org/wiki/Keypunch#IBM_029_Card_Punch Also, the Qume QVT-102, introduced in 1983. Ter

bug#47243: pr lacks -p

On 2025-07-28 21:39, Collin Funk wrote: Thanks for again for the thorough review and explanations. I find it funny that I assumed this change was simple and learned it's purpose was for logging in on a teletype. The Model 37 predates me ~30 years, so it never occured to me that the purpose was t

bug#47243: pr lacks -p

On 2025-07-28 10:36, Collin Funk wrote: I don't really like the idea of changing '-f' depending on whether POSIXLY_CORRECT is defined. So I would prefer this as well. On second thought (sorry...) I now think I understand why GNU pr behaves the way it does. The GNU coding standards[1] say "...p

bug#47243: pr lacks -p

On 2025-07-28 09:06, Stan Marsh wrote: The point is that -f is already taken; it is a synonym for -F. That's a bug in GNU 'pr'. -f is supposed to mean "act like -F but also pause before the first page if standard output is a terminal". See

bug#47243: pr lacks -p

On 2025-07-28 09:23, Pádraig Brady wrote: Yes it's a fair point. We don't want existing scripts that use -f to start pausing unexpectedly. I suppose this is a case for only pausing with -f if POSIXLY_CORRECT env var is set. Although backward compatibility is an issue, the current behavior is c

bug#47243: pr lacks -p

On 2025-07-27 19:21, Collin Funk wrote: I think that v3 attached should cover everything. In addition to Pádraig's comments, I would add: + a newline character is read from /dev/tty, as required by POSIX Issue + 6. The corresponding long option is --pause. Don't say "Issue 6" as almost

bug#47243: pr lacks -p

On 2025-07-28 07:41, Stan Marsh wrote: Paul Eggert writes: Thanks for looking into that. Unfortunately POSIX says -p should be ignored only if standard output is a terminal, and that newline should -^ Shouldn't this be "ignored unles

bug#79108: Meta Re: pr lacks -p

On 2025-07-27 18:10, Stan Marsh wrote: Just out of curiosity, why is shred obsolete? Oh, that's a long story. Some of it is covered in the manual here: https://www.gnu.org/software/coreutils/manual/html_node/shred-invocation.html but that's a bit out of date. Here's something that's more up-t

bug#79108: Meta Re: pr lacks -p

On 2025-07-27 17:26, Stan Marsh wrote: Just out of curiosity, I note that you (Paul) say that "pr" is "obsolete". This surprises me, since I still use it every day. I'm not proposing that we remove pr, just that it's not high priority. As this is not a bug

bug#47243: pr lacks -p

On 2025-07-27 17:19, Paul Eggert wrote: +  putc ('\a', stderr); A few more things. stderr might be line buffered, so this needs an fflush afterwards. If the putc or fflush fails, pr should diagnose and exit immediately (otherwise the user will wonder why pr stopped). A f

bug#47243: pr lacks -p

Thanks for looking into that. Unfortunately POSIX says -p should be ignored only if standard output is a terminal, and that newline should be read from /dev/tty, not from standard input. This is so that users can pipe into 'pr -p'. So the proposed patch needs some changes. Here are the issues I

bug#78476: GNU 'factor' problems with 128-bit word

Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 27 Jul 2025 07:30:29 -0700 Subject: [PATCH] doc: mention 2025 speedup on large composites --- NEWS | 3 ++- src/factor.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index 17a43b064..0b2be7116 100644

bug#79096: du: -x doesn't detect sshfs file system

On 2025-07-25 11:25, Stan Marsh wrote: it could be argued that -x should cause it to skip (i.e., not descend into) any directory which is a mountpoint That goes too far; people regularly use commands like 'du -x /mountpoint' to list just that file system. It sounds like we have a feature req

bug#79095: [PATCH] test: removed dead code for unrecognised binary operators

:00:00 2001 From: Paul Eggert Date: Fri, 25 Jul 2025 11:56:00 -0700 Subject: [PATCH] test: simplify for clarity This should help avoid further audit confusion, such as was just fixed by removing a FIXME. * src/test.c (enum binop): New type. (get_mtime): Return a struct timespec instead of returning

bug#79096: du: -x doesn't detect sshfs file system

Thanks for reporting it. Can you use 'strace' to find out which system call is hanging? That would help isolate whether the bug is in 'du' or is in the kernel. At some point we might ask whether you can reproduce the bug with the latest stable Coreutils

bug#25553: tabs still dont work 8 years after last ticket activity?

On 2025-07-23 08:25, Kent Dorfman wrote: feel free to call this tabs issue closed/shelved. Thanks, closing.

bug#79072: install -d onto readonly fs prints the wrong error

red in the neighborhood. Please give the patches a try. As they fix the bugs for me I am boldly closing the Coreutils bug report; we can reopen it if I'm wrong. From 27db579667399d9f2cae2552a6f9185ffd10ab23 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 22 Jul 2025 12:09:28 -0700 Subj

bug#25553: tabs still dont work 8 years after last ticket activity?

On 2025-07-20 12:23, Kent Dorfman wrote: In my old age I decided to start coding with tabs instead of "four spaces" so I set TABSIZE=4 in my shell and mostly my editors and xterms are OK with it.  However, there are some xterm window geometries that break column alignment for the (ls) command

bug#78985: sort-float failure on ppc64, LDBL_MIN fraction part too long for test command to parse

On 2025-07-12 04:45, Pádraig Brady wrote: -  : a == b ? 0 +  : a == b ? numcompare (sa, sb) That fails for string pairs like "10" and "1e1".

bug#78985: sort-float failure on ppc64, LDBL_MIN fraction part too long for test command to parse

On 2025-07-11 20:59, Collin Funk wrote: Maybe a solution would be to compare the strings instead of calling strold? Yes, that's been on the 'sort' TODO list for like, forever. It'd also be faster than what's in there now. A bit tricky, though, given the vagaries of textual floating point form

bug#78985: sort-float failure on ppc64, LDBL_MIN fraction part too long for test command to parse

On 2025-07-11 15:25, Collin Funk wrote: This test still fails on cfarm110 for me, logs attached. I guess that's a different issue, due to the problem that Gnulib defines LDBL_MAX to be a value greater than what one can compute from source code. I guess a fix on that platform would be to shri

bug#78985: sort-float failure on ppc64, LDBL_MIN fraction part too long for test command to parse

17 00:00:00 2001 From: Paul Eggert Date: Fri, 11 Jul 2025 14:43:32 -0700 Subject: [PATCH] tests: fix fraction comparison in sort-float Problem reported by Cosima Neidahl <https://bugs.gnu.org/78985#13>. * tests/sort/sort-float.sh: At top level, use C locale at first. (dbl_minima_order): As

bug#78985: sort-float failure on ppc64, LDBL_MIN fraction part too long for test command to parse

Thanks for reporting that false positive in the test. I installed the attached patch, which should fix things.From 8f9fc8f08c10c3b097211f95c6354a85d41f1101 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 10 Jul 2025 10:17:29 -0700 Subject: [PATCH] tests: fix integer overflow in sort-float

bug#78933: compilation error after recent 'od' changes

48281e56a399818fa6326b6519f1ba3d8b7d5488 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 30 Jun 2025 15:40:57 -0700 Subject: [PATCH] od: port to Apple clang 14 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * src/od.c (print_function_type): New type. Use

bug#78880: od Heap-buffer overflow

617220e970f267fbeea80d5cd8b62aec2ba7eaf6 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 29 Jun 2025 18:06:22 -0700 Subject: [PATCH 1/3] od: refactor parse_old_offset * src/od.c (parse_old_offset): Refactor for brevity and clarity. --- src/od.c | 32 +--- 1 file changed, 9 insertions(+), 23

bug#78880: od Heap-buffer overflow

On 2025-06-29 12:59, Pádraig Brady wrote: I've manually suppressed that error instance in our coverity instance. Maybe the change I just installed removed the need for that manual suppression?

bug#78880: od Heap-buffer overflow

pacifies GCC on your platform. I didn't observe the problem with gcc (GCC) 15.1.1 20250521 (Red Hat 15.1.1-2) on x86-64 so I can't easily test the patch myself.From dcdb2550c4a6480394fa3b6303a81c7f94461865 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 29 Jun 2025 17:12:07 -0700 S

bug#78880: od Heap-buffer overflow

he hacky fix doesn't require memory allocation so in some sense it's better than a cleaner one would be.From 0d1c25d1cb6d0ce119775368a0fabc7644393f6e Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 28 Jun 2025 08:15:42 -0700 Subject: [PATCH 01/19] od: fix theoretical size_t

bug#78879: Potential Out-of-Memory in coreutils od

On 2025-06-23 01:21, Jaehoon Jang wrote: This happens because the parsed -w value is passed to bytes_per_block, which is then used in a call to xnmalloc, leading to potentially dangerous memory allocation. "Dangerous" in the sense that if you give "od" a large task it needs a lot of RAM? If so

bug#78879: Potential Out-of-Memory in coreutils od

On 2025-06-24 06:03, Jaehoon Jang wrote: The issue here is not that "od" performs a large task, but that it allows unbounded, unchecked memory allocation from a single user-supplied argument, with no upper bound or safety net, leading to potential denial-of-service. The memory allocation *is*

bug#78857: shred bug

On 2025-06-21 07:57, KhorneTraditionalist via GNU coreutils Bug Reports wrote: Maybe, shred could reserve the drive name for itself until shredding could be completed so that automounting other drive could not lead to such issues? shred opens the named file at startup and never uses the file

bug#78853: [Bug]: Unexpected Behaviour with the `-r` (relative) `ln` - Parameter

On 2025-06-20 13:58, NA0341-Services (dev-account) wrote: In a conversation with the Claude 3 Haiku AI I confirmed that this is very likely to be a bug ~ since `ln` should only dereference the TARGET when the -L Option is given. The documentation for 'ln -r' says: Relative symbolic li

bug#26371: [PATCH 0/1] tty: do not provide conflicting information

On 2017-04-05 14:27, Paul Eggert wrote: In the meantime I suppose that the best plain 'tty' can do is report the configuration error and exit. After seeing a more-recent bug report <https://bugs.gnu.org/78244> about this I came up with what I think is a better patch fo

bug#78244: Exit code 4 whilst installing util-linux-selinux on arch

patch which should fix the test failure. Thanks for reporting it.From aec89a3e7dfaed1545b2dcaa8525df21cf61a37e Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 20 Jun 2025 11:53:21 -0700 Subject: [PATCH] tty: better fix for Bug#26371 * src/tty.c (TTY_USAGE): Rename from TTY_FAILURE, since th

bug#77597: listxattr() should return ENOTSUP for sysfs / tmpfs entries, not 0

On 2025-05-23 04:38, Pádraig Brady wrote: FYI this should be addressed with: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8b0ba61d Thanks for letting me know, as this led me to further testing that found some other kernel bugs in this area, possibly introduced

bug#78623: cp --preserve=xattr copies attr as well as xattr which breaks cross-FS copy

On 2025-05-30 02:37, Pádraig Brady wrote: we only have this issue with --preserve=xattr which diagnoses any issues. Perhaps we would benefit from a --preserve=supported-xattr option? If we go that route, it might be a bit better if the new option-arg began with 'xattr' rather than ended with

bug#78562: Coreutils-9.7 do not build on macOS High Sierra, Version 10.13.6, because src/cksum.c: uses invalid cpu feature string for builtin

On 2025-05-30 02:38, Peter Dyballa wrote: My assumption was that when tar has to extrapolate an exact timestamp to something inexact it needs rounding, which can make more than one file have the same timestamp. As far as I know, all 'tar' implementations floor (i.e., truncate towards minus i

bug#78562: Coreutils-9.7 do not build on macOS High Sierra, Version 10.13.6, because src/cksum.c: uses invalid cpu feature string for builtin

On 2025-05-29 10:25, Peter Dyballa wrote: MacPorts' Portfile is such a fine "remote control" As long as it doesn't try to run autoconf etc. I won't mind. Configure stopped configuring when it could not find "aclocal-1.16" or "aclocal-1.18", exactly these executables, because of reasons I do

bug#78562: Coreutils-9.7 do not build on macOS High Sierra, Version 10.13.6, because src/cksum.c: uses invalid cpu feature string for builtin

On 2025-05-29 01:12, Peter Dyballa wrote: First try with coreutils-9.7.39-c8d75 and Apple LLVM version 10.0.0 (clang-1000.11.45.5) AND without Pádraig's patch from a few days ago. I have to change 1.18 to 1.17 in aclocal.m4 and configure (for which I prepared patches to automate this). For f

bug#78509: Coreutils' mv and cp 9.5 do not work properly on old PPC Mac OS X 10.4.11, Tiger

On 2025-05-29 08:57, Peter Dyballa wrote: I think the coreutils are now OK! Thanks for checking; closing the two coreutils bug reports.

bug#78562: Coreutils-9.7 do not build on macOS High Sierra, Version 10.13.6, because src/cksum.c: uses invalid cpu feature string for builtin

On 2025-05-23 16:37, Pádraig Brady wrote: I suspect the following will avoid the issue: Given the followup emails, and the fact that vpclmulqdq is a not-always-implemented extension to AVX-512, it seems like the patch can't hurt and might help so I installed it.

bug#78562: Coreutils-9.7 do not build on macOS High Sierra, Version 10.13.6, because src/cksum.c: uses invalid cpu feature string for builtin

On 2025-05-29 08:11, Peter Dyballa wrote: where is the indication that Karl Berry's public key is needed? I suppose you're supposed to infer it from the release announcement by karl.

bug#78562: Coreutils-9.7 do not build on macOS High Sierra, Version 10.13.6, because src/cksum.c: uses invalid cpu feature string for builtin

On 2025-05-29 03:16, Peter Dyballa wrote: gpg: Can't check signature: No public key You can fix that by importing the public key of whoever signed the compressed tarball. See . E.g.: wget -O karl.key 'https://savannah.gnu.org/people/viewgpg.php?u

bug#78562: bug#78509: Coreutils' mv and cp 9.5 do not work properly on old PPC Mac OS X 10.4.11, Tiger

On 2025-05-28 13:19, Peter Dyballa via GNU coreutils Bug Reports wrote: I'll also check with diffutils,https://debbugs.gnu.org/db/77/77840.html. Is it possible, and advised, to use the Gnulib sources from coreutils-9.7.39-c8d75 in diffutils 3.12? I wouldn't advise it, as there are other chang

bug#78509: Coreutils' mv and cp 9.5 do not work properly on old PPC Mac OS X 10.4.11, Tiger

On 2025-05-24 12:57, Peter Dyballa wrote: The output is: "O_DIRECTORY incorrectly succeeded!" Thanks for checking. I installed fixes to Autoconf, Gnulib and Coreutils to try to address the two bug reports and . The fixes are so compli

bug#78509: Coreutils' mv and cp 9.5 do not work properly on old PPC Mac OS X 10.4.11, Tiger

On 2025-05-24 03:51, Peter Dyballa wrote: Yes, it does! It also build fine with -Os. Thanks, I installed that patch into Gnulib and it should appear in the next Coreutils release.

bug#78509: Coreutils' mv and cp 9.5 do not work properly on old PPC Mac OS X 10.4.11, Tiger

On 2025-05-24 11:45, Peter Dyballa wrote: This function in lib/targetdir.c, target_directory_operand(), seems to work OK: 63 if (must_be_working_directory (file)) evaluates to false 72 if (!O_DIRECTORY) evaluates to false – and we come to: 88 if (try_to_open) 89

bug#78509: Coreutils' mv and cp 9.5 do not work properly on old PPC Mac OS X 10.4.11, Tiger

On 2025-05-24 00:51, Peter Dyballa wrote: You are saying that the GNUlib function target_directory_operand() is known to fail when the target of cp or mv is a file? So I do not need to debug further? No, I'm saying that target_directory_operand is supposed to fail if it's given the name of a

bug#78509: Coreutils' mv and cp 9.5 do not work properly on old PPC Mac OS X 10.4.11, Tiger

On 2025-05-23 01:17, Peter Dyballa wrote: Undefined symbols: "_fchownat", referenced from: _chownat in libstdbuf_so-libstdbuf.o _lchownat in libstdbuf_so-libstdbuf.o "_fchmodat", referenced from: _chmodat in libstdbuf_so-libstdbuf.o

bug#78509: Coreutils' mv and cp 9.5 do not work properly on old PPC Mac OS X 10.4.11, Tiger

On 2025-05-23 04:27, Peter Dyballa wrote: 458 { 459 int fd = target_directory_operand (lastfile, &sb); 460 if (target_dirfd_valid (fd)) 461 { 462 x.rename_errno = -1; 463 target_dirfd = fd; 464

bug#78509: Coreutils' mv and cp 9.5 do not work properly on old PPC Mac OS X 10.4.11, Tiger

On 5/22/25 10:08, Peter Dyballa wrote: Somewhere in mv.c it happens that variable target-directory gets loaded with the value "out\0". Surely this occurs in src/mv.c's line "target_directory = d;". Please investigate how mv got there.

bug#78509: Coreutils' mv and cp 9.5 do not work properly on old PPC Mac OS X 10.4.11, Tiger

On 5/22/25 02:03, Peter Dyballa wrote: Trying to open on Macs non-existent "/proc/self/fd" could cause a failure state suggesting mv to fchdir into a file, "out"… Shouldn't be a problem, as when /proc/self/fd doesn't work, coreutils is supposed to fall back on older approaches (these have rac

bug#78509: Coreutils' mv and cp 9.5 do not work properly on old PPC Mac OS X 10.4.11, Tiger

On 5/22/25 10:08, Peter Dyballa wrote: when nullptr value changes to "out\0". I think GNU gdb 6.3.50-20050815 (Apple version gdb-696) (Sat Oct 20 18:20:28 GMT 2007) could be instructed to watch over a variable – but have no idea how. Is this a watchpoint? Yes, it's the GDB command 'watch targ

bug#78507: [Security] Heap Buffer Overflow in GNU Coreutils sort (CWE-122)

On 2025-05-20 10:15, Pádraig Brady wrote: The attached patch addresses the issue here, and includes a test verified to trigger with ASAN or valgrind available. Thanks. A nit: the patch doesn't include the change to NEWS.

bug#78509: Coreutils' mv and cp 9.5 do not work properly on old PPC Mac OS X 10.4.11, Tiger

On 2025-05-20 09:12, Peter Dyballa via GNU coreutils Bug Reports wrote: 126 + mv k out 127 mv: cannot stat 'out/k': Not a directory First, please build and run coreutils 9.7 and try that instead. If it works, we're done. (For what it's worth, I just now built and ran coreutils 9.7 on

bug#78476: GNU 'factor' problems with 128-bit word

On 5/19/25 15:23, Torbjörn Granlund wrote: Paul Eggert writes: before my Saturday coreutils commit[1], this code in prime_p: /* We have already cast out small primes. */ if (n < (wide_uint) FIRST_OMITTED_PRIME * FIRST_OMITTED_PRIME) return true; was incorrect. Why

bug#78476: GNU 'factor' problems with 128-bit word

On 2025-05-18 02:07, Torbjörn Granlund wrote: I don't think is makes much sense to handle two 128-bit words in this code. In fact, the use of uintmax_t was a mistake, it should use "unsigned long" or "unsigned long long" whichever is efficiently supported directly by the hardware. Fine, but t

bug#78476: GNU 'factor' problems with 128-bit word

I recently found out that GNU coreutils 'factor' misbehaves if its internal word is 128 bits rather than the usual 64. This could happen if one builds Coreutils 9.7 on a platform with 128-bit uintmax_t, something that POSIX allows (though it's only theoretical now as far as I know). The proble

bug#78431: Unclear patch submission address

On 2025-05-15 03:38, Pádraig Brady wrote: I haven't strong opinions on this, so am happy to go with the proposed patch. Thanks, I applied it and am closing the bug report.

bug#78431: Unclear patch submission address

t/coreutils.git/commit/?id=8b6d3c5700526f962b12cd5901b55961c5e18186From 9fa1367b66027ad402f11441417449ba96db3c04 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 14 May 2025 13:36:40 -0700 Subject: [PATCH] maint: --help now outputs bug reporting address MIME-Version: 1.0 Content-Type: text/pla

bug#78377: Cross-Compile - "src/make-prime-list: cannot execute: required file not found"

On 2025-05-13 10:01, Collin Funk wrote: Doesn't crc32 in Gnulib handle this using $(BUILD_CC)? I imagine it should be simple to do the same here. I can have a look later. Yes, that should work, so long as the build host isn't a Microsoft Windows platform that would require $(BUILD_EXEEXT). And

bug#78376: Llvm & Musl Libc - "function-like macro '__GNUC_PREREQ' is not defined"

Thanks, I pushed that patch into coreutils master on Savannah. Closing the bug report.

bug#78328: Copy fails setting system.nfs4_acl extended attribute [cp (GNU coreutils) 9.7.7-6218c]

On 2025-05-10 23:39, Ian Dall wrote: This works for me. Thanks for checking. Marking the coreutils bug report as done.

bug#78328: Copy fails setting system.nfs4_acl extended attribute [cp (GNU coreutils) 9.7.7-6218c]

h out. I didn't reproduce the bug on my RHEL 9.5 host with a NetApp NFS server, but NFS is kinda tricky that way.diff --git a/ChangeLog b/ChangeLog index 9cc1032a85..3d32510130 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,33 @@ +2025-05-09 Paul Eggert + + acl-tests: link with $(FILE_H

bug#77597: coreutils 9.6: regression in handling security.selinux attribute for ls(1)

On 4/7/25 12:04, Pádraig Brady wrote: The attached gnulib patch passes quick tests here. This causes 'ls' to issue more syscalls per file, right? It'd be better if we could figure out a workaround just for the affected platforms, as opposed to slowing down 'ls' for everybody.

bug#77621: coreutils-9.6.53-14af8 on OpenBSD 7.6

On 2025-04-07 16:06, Pádraig Brady wrote: I have access to cfarm220.cfarm.net, so I'll look at this tomorrow. I don't see the problem on cfarm220.cfarm.net with the current coreutils commit (42f6201aa554fde4c78a3c5d0207d85392eb742e), using "./configure && make -j5 check" . The command "src/ls

bug#77597: coreutils 9.6: regression in handling security.selinux attribute for ls(1)

On 2025-04-07 15:52, Pádraig Brady wrote: So maybe we class this as a kernel bug and have the kernel return non 0 for this case, or even ENOTSUP. Yes, this sounds right to me. The kernel should not pretend that there are no attributes when there are attributes. If the kernel doesn't want to t

bug#77597: coreutils 9.6: regression in handling security.selinux attribute for ls(1)

On 4/5/25 18:49, Rahul Sandhu wrote: the security context xattr only shows when specifically requesting it by passing the arguments -n 'security.selinux' to the command line: rsandhu@graphite ~ $ getfattr -d -m '' /run/credentials rsandhu@graphite ~ $ getfattr -n 'security.selinux' /run/credent

bug#77535: timeout treats very short durations as `0`

On 2025-04-05 12:41, Pádraig Brady wrote: +Note it's best to avoid combining suffixes with hexadecimal arguments, +as any @samp{d} will @emph{not} be interpreted as a suffix. But 'd' is interpreted as a suffix with hexadecimal arguments that have an exponent. For example, 'sleep 0x1p0d' sleeps

bug#77535: timeout treats very short durations as `0`

b7c210d30c5a6a4a879bda96d61926d77f16d96 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 7 Apr 2025 00:30:14 -0700 Subject: [PATCH] =?UTF-8?q?timeout:=20don=E2=80=99t=20sleep=20less=20than?= =?UTF-8?q?=20requested?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-

bug#77535: timeout treats very short durations as `0`

the patch the code mishandles 16777216.1 (2**24 + 10**-9) by treating it as if it were just 16777216. These are tiny bugs, I know, but I took up the challenge of doing this things more correctly by installing the attached.From a3b862ece2aa04d5c0b5e93fec8e66e45b9b3560 Mon Sep 17 00:00:00 20

bug#76876: logname output is often wrong when linked with glibc

On 2025-03-09 11:49, Bruno Haible wrote: Nicolas Boos wrote: This page says that the result of the logname command and the LOGNAME variable must be the same: https://www.ibm.com/docs/en/aix/7.3?topic=l-logname-command An AIX man page is not a specification for what we run on GNU systems. Plus

bug#76876: logname output is often wrong when linked with glibc

On 2025-03-09 09:04, Bernhard Voelker wrote: That gnulib commit will only be available with the next gnulib update in coreutils, obviously. Yes, and just now I installed that update.

bug#76876: logname output is often wrong when linked with glibc

which also occurs with getlogin_r.From 2a60c939bec320abe18737360bb9841595f5d8d1 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 8 Mar 2025 15:36:33 -0800 Subject: [PATCH] getlogin: document musl bug Problem reported by Nicolas Boos <https://bugs.gnu.org/76876>. --- ChangeLog

bug#76290: "sort -u" vs "sort -h -u": possible bug

s clearer without adding so much length.From 3324344820b6f3566ed659befe9bbfcf2b1f1298 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 19 Feb 2025 13:17:48 -0800 Subject: [PATCH] sort: improve -u brief doc * src/sort.c (usage): Reword -u help (Bug#76290). --- src/sort.c | 5 ++--- 1 file changed, 2 insertions(+), 3 delet

bug#73928: Bug#1080330: coreutils: who no longer works

On 2/19/25 09:41, Arsen Arsenović wrote: they (gdm) are a user and they have a session. Adding additional filtration can only confuse admins who compare 'who' and other tools. It is exactly that confusion that I'm trying to prevent. The man page for "who" says "who - show who is logged on", bu

bug#73928: Bug#1080330: coreutils: who no longer works

On 2025-02-19 03:26, Arsen Arsenović wrote: The case for or against there being a user called 'gdm' when one installs a Fedora system is one best presented to the Fedora hackers It's not just Fedora, it's also Ubuntu. Both systems have pseudousers named "gdm" that cannot log in (their login sh

bug#76290: "sort -u" vs "sort -h -u": possible bug

On 2025-02-17 15:13, Rupert Gallagher via GNU coreutils Bug Reports wrote: I expect the program to do exactly what the manual says. Here's what the manual says about -u in : Normally,

bug#76290: "sort -u" vs "sort -h -u": possible bug

On 2025-02-17 15:13, Rupert Gallagher wrote: ~ $ echo -e "a1\na2" | sort a1 a2 ~ $ echo -e "a1\na2" | sort -h a1 a2 Since A = B, the result of -u must be the same on both sets, by logic. By that logic, since the output of these two commands: echo -e 'a1\na2' | sort echo -e 'a1\na2' | sor

bug#76360: cksum crc broken with VMULL on musl

Thanks for the bug report. I installed the attached patches; please give them a try, as I don't have easy access to that platform.From c98e90b074429adb3492d7b79c3a69bad5c07f5f Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 17 Feb 2025 02:23:52 -0800 Subject: [PATCH 1/2] cksum: fix

bug#73928: Bug#1080330: coreutils: who no longer works

On 2025-02-17 00:22, Thorsten Kukuk wrote: Maybe that systemd version is too old on that systems? The systemd versions are reasonably recent. Fedora 41 has systemd 256.11 (2025-01-08) and Ubuntu 24.10 has systemd 256.5 (2024-08-31). Here are the details: On Fedora 41, "systemctl --version"

bug#73928: Bug#1080330: coreutils: who no longer works

On 2025-02-17 00:12, Bruno Haible wrote: Paul Eggert wrote: $ ./who-no-systemd # Configured normally. eggert seat02025-02-15 10:11 (login screen) eggert tty2 2025-02-15 10:11 (tty2) $ ./who-with-systemd # Configured with --enable-systemd. eggert seat0

bug#73928: Bug#1080330: coreutils: who no longer works

On 2025-02-16 23:03, Thorsten Kukuk wrote: The problems were already all solved with the first coreutils versions having systemd-logind support. Even with all the bug reports I don't see a need for changes in Coreutils, only in distributions not enabling systemd-logind support in all packages.

bug#73928: Bug#1080330: coreutils: who no longer works

At this point I confess I don't know what changes would be needed for GNU 'who'. I see a difference of opinion as to whether 'w' works. There seem to be multiple mechanisms in play (utmp, wtmp, wtmpdb, lastlog2, logind, maybe others?) and I don't know when to use which, or even how to use them

bug#76290: "sort -u" vs "sort -h -u": possible bug

On 2025-02-16 03:02, Rupert Gallagher wrote: The introduction of the unique operator (-u) returns a wrong answer when used with the human sorting operator (-h). The answer is "wrong" only in the sense that sort's documented and implemented behavior is not what you expect. To fix this mismat

bug#76316: date: forgot the full day of the month name

On 2025-02-16 00:09, Dan Jacobson wrote: PE> Sorry, I don't understand the bug report. Are you asking for a new PE> feature, or are you saying that currently GNU 'date' outputs incorrect PE> strings for %A and/or %B? If the former, what new feature exactly? And Yes the former. OK, marking this

bug#66329: [PATCH] dircolors: recognize “jxl” (JPEG XL) files

On 2023-10-03 16:02, Mike Swanson wrote: +.jxl 01;35 Thanks, I installed that.

bug#74426: tests/dd/skip-seek-past-file failure on macOS

your email until now. This patch appears in coreutils 9.6.From cc58b657361bf6d5467753ee547d3a1266a6cc7f Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Wed, 20 Nov 2024 11:11:54 -0800 Subject: [PATCH] dd: port big-offset test to macOS 12.6 * tests/dd/skip-seek-past-file.sh: Do not assume that seek

bug#76290: "sort -u" vs "sort -h -u": possible bug

I don't see a bug there, just an infelicity. -h means 'sort' should look for a number, and your data lines don't start with numbers. Try 'sort --debug -h -u' to see more.

bug#76316: date: forgot the full day of the month name

$ man date|grep "locale's full" %A locale's full weekday name (e.g., Sunday) %B locale's full month name (e.g., January) $ LC_ALL=zh_TW.UTF-8 date +%A%B 週日二月 OK that's great. But you forgot locale's full day of the month name E.g., I'll add it on the back for 2/

  1   2   3   4   5   6   7   8   9   10   >