bug#79410: Error in expr match handling patterns with null expression subpatterns

On 2025-09-08 10:05, Michael Figiel via GNU coreutils Bug Reports wrote: The expected behaviour is on FreeBSD and OpenBSD, so different code base, but I think it's more consistent with the POSIX description of expr. My reading of POSIX is that the GNU behavior is required and the FreeBSD behav

bug#79381: patch needed after gnulib changed

Thanks, I installed that and am closing the bug report.

bug#79336: [PATCH] df: fix potential null pointer dereference

Closing the bug report.From c6397d08725e651fe81fbbd91df2043674206865 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 1 Sep 2025 09:55:29 -0700 Subject: [PATCH] df: pacify static analysis Problem reported by Yubiao Hu <https://bugs.gnu.org/79336>. * src/df.c (get_dev): Assume MOUNT_P

bug#79336: [PATCH] df: fix potential null pointer dereference

On 8/31/25 18:58, yubiao hu wrote: Yes, this bug was identified via static code analysis. The initial finding that core dump would occur in `cell = xstrdup (mount_point);` when mount_point is NULL. It appears that the static analysis is reporting a false positive. Which static analyzer are you

bug#79336: [PATCH] df: fix potential null pointer dereference

8d9accfb471bd6e1aa4568ea4073413ce341283b Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 30 Aug 2025 10:39:49 -0700 Subject: [PATCH] df: pacify static analysis Problem reported by Yubiao Hu <https://bugs.gnu.org/79336>. * src/df.c (get_dev): Assume MOUNT_POINT is non-null. --- src/df.c | 12 ++-- 1 file chan

bug#79328: expr: memory not freed before program exit(memory leak)

On 2025-08-28 01:08, Collin Funk wrote: Most (all?) of the programs in Coreutils will not free memory before exit, since it just takes extra time for no benefit. Not only does it take extra time (and sometimes even space!), it makes the programs slightly less reliable because if there are bugs

bug#79261: coreutils 9.7 "date -u" - timezone offset is in the wrong direction

On 8/26/25 08:43, James Feeney wrote: Your definition of "longstanding" seems a bit disingenuous, since this change, from the default POSIX `date -u` 24 hour format to the 12 hour format, was made in 2020 ? No it wasn't. I just now ran 'date -u' from the coreutils 5.93 (2005) shipped with Sol

bug#79261: coreutils 9.7 "date -u" - timezone offset is in the wrong direction

On 2025-08-25 14:15, James Feeney via GNU coreutils Bug Reports wrote: For anyone inclined to accept my appeal to ISO 8601, the current display format returned by `date -u`, especially within the USA, is wrong, and that is a bug that needs to be fixed. Are you inclined to accept the time forma

bug#79261: coreutils 9.7 "date -u" - timezone offset is in the wrong direction

On 2025-08-24 14:33, James Feeney via GNU coreutils Bug Reports wrote: reporting UTC in 12 hour format is just plain wrong. No it's fine, actually. UTC is a world-wide standard; it's not local to Greenwich. Many people prefer 12-hour format, and there's nothing wrong with displaying UTC that

bug#79267: cp --sparse=auto heuristic fails on a squashfs mounted drive.

On 2025-08-23 11:46, Phillip Lougher wrote: As far as Squashfs is concerned SEEK_HOLE/SEEK_DATA is easy to implement.  So I'll think about adding it as a build option. Thanks, that'll be helpful. But this isn't going to fix it for any other case. Right, and bleeding-edge coreutils already h

bug#79267: cp --sparse=auto heuristic fails on a squashfs mounted drive.

On 2025-08-23 11:27, Phillip Lougher wrote: Yeah let's take the attitude everyone writes well written programs, and if they don't it's their fault when they unexpectedly break in production. In reality a lot of code in embedded Linux systems is dreadful, written by inexperienced programmers

bug#79267: cp --sparse=auto heuristic fails on a squashfs mounted drive.

On 2025-08-22 19:11, Phillip Lougher wrote: any Squashfs SEEK_HOLE/SEEK_DATA implementation will not behave like other Linux filesystems, because it won't report sparseness at the 4K granularity that most people or programs will expect it to. Coreutils doesn't expect 4 KiB granularity for LSEEK

bug#79267: cp --sparse=auto heuristic fails on a squashfs mounted drive.

atches? Thanks. From 306de6c2619e2a9339ade9a88d55c4940942d516 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 22 Aug 2025 10:37:50 -0700 Subject: [PATCH 1/2] cp: go back to copy_file_range optimization This reverts part of the previous change. * src/copy.c (lseek_copy): When calling sparse_copy, do not ask it to scan for z

bug#79267: cp --sparse=auto heuristic fails on a squashfs mounted drive.

Thanks for checking; closing the bug report.

bug#79267: cp --sparse=auto heuristic fails on a squashfs mounted drive.

Thanks for the bug report. Although this part of the code is messy and needs a revamp, in the meantime I installed the attached into the master branch on Savannah; please give it a try.From b7fc76269bbc830bf96320cd5cca3cfd90d33f68 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 21 Aug

bug#69939: test utility bug: "test -a -a -a" and "test -o -o -o" fail

On 8/14/25 21:18, Collin Funk wrote: Just adding here that POSIX.1-2024 removed the -a and -o operators [1]: Austin Group Defect 1330 is applied, removing the obsolescent (and optional) -a and -o binary primaries, and '(' and ')' operators. So I don't think we should spend much time w

bug#79232: tsort doesn't support -w added by POSIX 2024.

of it, how about setting MAX_CYCLES to 1? There's no real use for values greater than 1. This is much simpler (it avoids the abovementioned problems among other things), and POSIX allows this. Proposed patch attached.From c4c62ff7fd9dacb4bf1bc72ae65c24d026857109 Mon Sep 17 00:00:00 2001 From

bug#79232: tsort doesn't support -w added by POSIX 2024.

On 8/14/25 04:45, Pádraig Brady wrote: So we could just always exit >= 125 on error, and it would suffice to mention this in NEWS under "Change in behavior". But I'm inclined to only do the exit status adjustments if -w was specified. and just document the exit status range in the info docs f

bug#79221: basenc triggers undefined-behaviour in mini-gmp

Thanks, I installed that.

bug#79184: base32/base64: different behavior of -d with invalid input

On 2025-08-06 09:04, Daniel Hofstetter wrote: $ echo 'invalid' | base32 -d 2> /dev/null $ echo 'invalid' | base32 -d > /dev/null base32: invalid input $ echo 'invalid' | base64 -d 2> /dev/null �{ږ'$ $ echo 'invalid' | base64 -d > /dev/null base64: invalid input I don't see a bug here. Both prog

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-

  1   2   3   4   5   6   7   8   9   10   >