bug#69770: [PATCH] build: strengthen 16 bit float support checks

On 3/14/24 6:03 AM, Pádraig Brady wrote: > It would disable this feature for cross-compilation yes, > but this isn't the first instance of AC_RUN_IFELSE we use. Sorry if this is not the proper place to ask, but would it be possible to make Autoconf use an emulator when cross-compiling? This issue

bug#69770: [PATCH] build: strengthen 16 bit float support checks

On 3/14/24 7:48 AM, Pádraig Brady wrote: > For completeness I should add that the above check can be > overridden if cross-compiling or whatever like: > > ./configure utils_cv_ieee_16_bit_supported=yes > utils_cv_brain_16_bit_supported=yes Ah, thanks. I wasn't aware of this. > Interesting. >

bug#70298: uname -i returns unknown since fedora 38

On 4/9/24 12:57 AM, Paul Eggert wrote: > Indeed there is, and I merged your bug report into that old one. It'd be nice > if someone could get to the bottom of that bug. I decided to look into this a bit, since I also have an unknown 'uname -i' and 'uname -p'. It seems that this option is a Solar

bug#70639: Bug or Misleading Description of realpath command

On 4/28/24 4:37 PM, Hazel Cooney wrote: > To reproduce this bug, create a directory with some files in it. Then, go > to the directory that contains the one you just made. Type ls new_directory > | xargs realpath. Using 'build-aux' for my directory instead of music_copy. We have this for build-aux

bug#73068: printf: please implement POSIX:2024 argument reordering

Hi Pádraig, Pádraig Brady writes: > I'll apply the attached sometime tomorrow. > > Marking this as done. Patch looks good, thanks. One small comment, though. > +#define GET_CURR_ARG(POS)\ > +do { \ > + char *arge;

bug#76409: Failure in parallel make?

"Philip Rowlands" writes: > Is there a dependency problem in the generated Makefile? FWIW I see similar > errors trying to build src/cp and src/mv. > > src/sort$(EXEEXT): $(src_sort_OBJECTS) $(src_sort_DEPENDENCIES) > $(EXTRA_src_sort_DEPENDENCIES) src/$(am__dirstamp) > @rm -f src/sort$

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

t am' on the attached patch. Or wait until a Coreutils maintainer does the same and pushes the change. Collin >From 7bc983dde89f2fa736846087cf796ab32c64b5cb Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Sun, 11 May 2025 09:56:37 -0700 Subject: [PATCH] build: update gnulib submodu

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

Pádraig Brady writes: > The workaround isn't too onerous, > but yes it would be good to clean this up. 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. Collin

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

Hi Pádraig, Pádraig Brady writes: > Well given we also need to call gl_BUILD_CC perhaps the > best way would be to have a separate build-cc gnulib module > and have the crc module depend on that. I'm fine just depending > on crc for now though, though I can see a build-cc gnulib module > being g

bug#78431: Unclear patch submission address

Ville Skyttä writes: > The HACKING and README-hacking files contain advice to send patches to the > email address in the respective program's --help output. > > However, --help output might not contain any email addresses, such as for > example in the coreutils that ships with Ubuntu 25.04. Looks

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

l --copy-file m4/build-cc.m4 } Like we do for tests/init.sh. Collin >From 9dab53ad3f15e0482020253f3f87f7be03748d53 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Thu, 15 May 2025 22:02:26 -0700 Subject: [PATCH] build: allow make-prime-list to build when cross-compiling * src/local.m

bug#78431: Unclear patch submission address

Paul Eggert writes: > Yes, now's a good time to revisit the decision in 2013 to remove the > bug-reporting email address[1]. Plus, the current code is confusing. > > How about the attached coreutils patch? It simplifies the code and > goes back to the old way of doing things, which includes outpu

bug#78882: stty.c compilation error

Bruno Haible writes: > Yes, I had the same thought. Done through > . Thanks! That looks good. Collin

bug#78882: stty.c compilation error

Hi Bruno, Bruno Haible via GNU coreutils Bug Reports writes: > It looks like the 'speedgen' script, added in commit > 357fda90d15fd3f7dba61e1ab322b183a48d0081, produces this invalid C code. > > With GNU sed: > > $ echo 100 | sed -e 's/^.*$/# ifdef B&\n case B&: return &;\n# endif/' > # i

bug#78910: tail does not support -r added by POSIX.1-2024

Creating this bug report since I have not been able to create a working implementation yet, and perhaps my looking into this will inspire others thoughts... POSIX-1.2024 adds the following SYNOPSIS for 'tail' [1]: tail [-f] [-c number|-n number] [file] tail -r [-n number] [file] Where th

bug#78910: tail does not support -r added by POSIX.1-2024

Pádraig Brady writes: > On 27/06/2025 20:16, Collin Funk wrote: >> Hi Jim and Pádraig, >> Jim Meyering writes: >> >>>> tail -r comes from the BSDs. >>>> Also the BSDs don't have tac(1) which overlaps in functionality quite a >>>>

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

Paul Eggert writes: > On 2025-07-11 04:28, C. Neidahl wrote: >> The LDBL_MIN fraction is longer than the DBL_MIN fraction, so it >> appears as a bigger number to test/expr > > Oh, right. Thanks. I installed the attached further patch to fix that. > This is cleaner anyway. This test still fails o

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

Collin Funk writes: >> Oh, right. Thanks. I installed the attached further patch to fix that. >> This is cleaner anyway. > > This test still fails on cfarm110 for me, logs attached. > > I was looking at it the other day, but was unable to get a working > version. >

bug#78880: od Heap-buffer overflow

Pádraig Brady writes: > On 24/06/2025 15:27, Grisha Levit wrote: > >> This part: >> >>> tryline: >>> + idx_t i = 0; >>> + int c = 1; /* Init to 1 so can distinguish if NUL read. */ >> triggers >> warning: label followed by a declaration is a C23 extension >> [-Wc23-e

bug#78910: tail does not support -r added by POSIX.1-2024

Hi Eric, Eric Blake writes: > Remember, the POSIX synopsis lines lists two distinct invocation > styles: > > tail [-f] [-c number|-n number] [file] > tail -r [-n number] [file] Yep, I was going to mention this too. But I was not sure if it should have a mention in the description to make it mor

bug#78880: od Heap-buffer overflow

Hi Paul, Paul Eggert writes: > * src/od.c (width_bytes, decode_one_format): Don’t assume a signed > type has the same size as the corresponding unsigned type. > This has no effect on practical platforms; it’s just for > consistency there. > --- > src/od.c | 18 +- > 1 file chang

bug#78910: tail does not support -r added by POSIX.1-2024

Hi Jim and Pádraig, Jim Meyering writes: >> tail -r comes from the BSDs. >> Also the BSDs don't have tac(1) which overlaps in functionality quite a bit. >> I'm a bit surprised -r was added by POSIX, but fair enough. > > "Surprised" is putting it lightly. I am disappointed and am tempted to > pus

bug#78880: od Heap-buffer overflow

Hi Grisha, Grisha Levit writes: >> Grisha, what did you pass to ./configure? >> >> I'm suprised we don't disable this in Gnulib. Since there we do: >> >> static_assert (1 < sizeof (example)) >> >> Without a second argument message string, I would expect Clang to >> complain about it, unless

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

ade9cb9aa5a9f5fa9cc6458 Mon Sep 17 00:00:00 2001 Message-ID: <822da07feb7862acbade9cb9aa5a9f5fa9cc6458.1753164543.git.collin.fu...@gmail.com> From: Collin Funk Date: Mon, 21 Jul 2025 23:02:55 -0700 Subject: [PATCH] mkdir-p: Diagnose read-only file systems. * lib/mkdir-p.c (make_d

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

Pádraig Brady writes: > Seems to work with the attached coreutils patch > to add NEWS and a test. Looks good, thanks. And thanks Paul for the fix. Collin

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

test_syntax_error (_("-ef does not accept -l")); I pushed the attached patch to fix it. We can just place the argument on another line. Collin >From ba8e55ea95c6e13ec1ab05ef3c9060c55f5c7043 Mon Sep 17 00:00:00 2001 Message-ID: From: Collin Funk Date: Sat, 26 Jul 2025 00:17:16 -

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

Hi Stan, Haven't gotten a chance to read through the original report yet, but... Stan Marsh writes: > By the way, and just out of curiosity, what method does "du" use to figure > out if > something is a mountpoint (and thus to be skipped if -x was supplied on the > cmd line) ? We have a func

bug#47243: pr lacks -p

tch? Collin >From 5b4ac990e8dd43d8f3e1371e2e78271c9b35345e Mon Sep 17 00:00:00 2001 Message-ID: <5b4ac990e8dd43d8f3e1371e2e78271c9b35345e.1753655792.git.collin.fu...@gmail.com> From: Collin Funk Date: Sun, 27 Jul 2025 15:00:15 -0700 Subject: [PATCH] pr: implement '-p' as

bug#47243: pr lacks -p

Hi Pádraig, Pádraig Brady writes: >>> Given that hardly anybody uses pr any more, I'm surprised that the >>> Austin Group still cares about its options. It's an obsolete utility, >>> and ought to be deprecated. >> True, but this option seems simple enough to implement. >> How about the attached

bug#47243: pr lacks -p

Collin Funk writes: > I have attached the V2 patch [...] Oops, forgotten patch attached here. Collin >From 6927ed786c87d0849f70e20459672fcff0d114bd Mon Sep 17 00:00:00 2001 Message-ID: <6927ed786c87d0849f70e20459672fcff0d114bd.1753659226.git.collin.fu...@gmail.com> From: Colli

bug#79118: CI test failures

Collin Funk writes: >> + case $(date --iso-8601=hours) in >> ++ date --iso-8601=hours >> + fail=1 >> + case $(date --rfc-3339=date) in >> ++ date --rfc-3339=date >> + fail=1 > > My guess is that `date ...` or a separate assignment will be needed >

bug#79118: CI test failures

Hi Bruno, Bruno Haible via GNU coreutils Bug Reports writes: > Today's CI run reports that the new tests > tests/date/date-ethiopia > tests/date/date-iran > tests/date/date-thailand > fail on OpenBSD and macOS. Thanks for the report. I'll fix them later today. > On OpenBSD, that's expect

bug#79118: CI test failures

Hi Bruno, Collin Funk writes: > The issue is that they return the non-C locale date. The code we use > when --iso-8601 or --rfc-3339 is in use is the following: > > if (use_c_locale) > setlocale (LC_TIME, "C"); > > bool ok = show_date (format, when,

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

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

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

Paul Eggert writes: > 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 That is an unfortunate bug. Thanks and good catch Leah. > I should have a Gnulib f

bug#62385: POSIX behavior of readlink, realpath

icalize if it is successful. Collin >From 49d32775db13eb3f272853eb1c7124fff17b93f8 Mon Sep 17 00:00:00 2001 Message-ID: <49d32775db13eb3f272853eb1c7124fff17b93f8.1754194901.git.collin.fu...@gmail.com> From: Collin Funk Date: Sat, 2 Aug 2025 20:51:30 -0700 Subject: [PATCH] readlink: emit er

bug#62385: POSIX behavior of readlink, realpath

d2ce49e46babd3657c455d9b2419102 Mon Sep 17 00:00:00 2001 Message-ID: From: Collin Funk Date: Sat, 2 Aug 2025 20:51:30 -0700 Subject: [PATCH v2] readlink: emit errors when POSIXLY_CORRECT is set * src/readlink.c (main): Set verbose if the POSIXLY_CORRECT environment variable is set. * tests/readlin

bug#62385: POSIX behavior of readlink, realpath

Pádraig Brady writes: >> Done, v2 attached. > > Looks good. Pushed, thanks to you and Dmitry for the review. Leaving this bug open for realpath. I'll have a look at that as well, just requires some more reading than readlink did. :) Collin

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

bug#62385: POSIX behavior of readlink, realpath

Hi Paul, I should have waited a few minutes before pushing. Oops... Paul Eggert writes: > 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 t

bug#47243: pr lacks -p

Paul Eggert writes: > 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

bug#79108: Meta Re: pr lacks -p

>>As this is not a bug I'll be bold and close the bug report. > > Quite so. It'd be nice if there as some way to prevent the system from > assigning a > bug number. I.e., some kind of code you could put in your email to say "This > is not > a bug; it is just meta". I think coreut...@gnu.org

bug#47243: pr lacks -p

2b1a9a.1753669052.git.collin.fu...@gmail.com> From: Collin Funk Date: Sun, 27 Jul 2025 15:00:15 -0700 Subject: [PATCH v3] pr: implement '-p' as required by POSIX Issue 6 * src/pr.c (pause_option): New variable. (tty_fp): Likewise. (short_options): Add '-p'. (long_options): Add &#

bug#47243: pr lacks -p

Paul Eggert writes: > 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 G

bug#47243: pr lacks -p

Paul Eggert writes: > 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

bug#47243: pr lacks -p

Pádraig Brady writes: > Reading POSIX more closely I see there is also pause logic for the first page > only: > -f[XSI] [Option Start] Use a for new pages, instead of the > default behavior that uses a sequence of characters. > Pause before beginning the first page if the standa

bug#47243: pr lacks -p

p 17 00:00:00 2001 Message-ID: <8afb79bbf294687fd4bdd3c92d1599f5021f703a.1753850358.git.collin.fu...@gmail.com> From: Collin Funk Date: Sun, 27 Jul 2025 15:00:15 -0700 Subject: [PATCH v5] pr: implement '-p' and modify '-f' conforming to POSIX * src/pr.c (last_paused_page

bug#47243: pr lacks -p

Pádraig Brady writes: > 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. >> Sure, but d

bug#79118: CI test failures

Bruno Haible writes: > There are basically two ways to fix this: > (a) set the appropriate environment variables (instead of setlocale calls), > (b) add an nstrftime_l and fprintftime_l variant and pass a locale that > has "C" for the LC_TIME category. > > (b) is more hairy, when it com

bug#79118: CI test failures

tags 79118 fixed close 79118 stop Collin Funk writes: > Bruno Haible writes: > >> There are basically two ways to fix this: >> (a) set the appropriate environment variables (instead of setlocale calls), >> (b) add an nstrftime_l and fprintftime_l variant and pass a