bug#79445: `ln -s` should raise a warning about pwd-relative vs symlink-location-relative targets

Paul Eggert writes: > On 2025-09-13 03:16, Chris wrote: >> It seems to me it should be easy enough to alert users to this gotcha by >> printing a warning to stderr when creating a symlink > > I dunno, that gotcha has been present in Unix and Linux for nearly 50 > years now, and lots of people are

bug#79444: baseenc SIGSEGV on macOS

Collin Funk writes: > That is my hypothesis at least, will need to write a patch to test it. Looks like my hypothesis was correct. I ran the CI with the attached patch, and everything passes. I'll hold off pushing until Pádraig checks it. Since he may want to revisit his previous co

bug#79444: baseenc SIGSEGV on macOS

Pádraig Brady writes: > There may be more cleanups I might do in this area, > but we should commit this fix anyway. Done, thanks. Collin

bug#79444: baseenc SIGSEGV on macOS

Bruno Haible writes: > Here's the relevant output on macOS 13: > > empty1d... > Running command: 'basenc --base64 -d 'empty1d.1' > empty1d.O 2> empty1d.E' > sh: line 1: 79138 Segmentation fault: 11 basenc --base64 -d 'empty1d.1' > > empty1d.O 2> empty1d.E > basenc.pl: test empty1d failed: exit

bug#79444: baseenc SIGSEGV on macOS

Bruno Haible via GNU coreutils Bug Reports writes: > Today's CI (coreutils master, gnulib master) reports a test failure on > macOS 13 and macOS 15. > > > On macOS 13: > > FAIL: tests/basenc/basenc > = > [...] > sh: line 1: 70606 Segmentation fault: 11 basenc --base64 -d

bug#70411: [bug] install(1) fails to read /dev/stdin on Darwin

Sergei Trofimovich writes: >> > > This is a kernel bug in macOS. Can you report it or otherwise >> > > arrange to have the kernel bug fixed? I expect that you have >> > > better connections with Apple than I do. A proposed patch >> > > (relative to xnu-10063.101.15) is attached; I have not tested

bug#79301: fold-spaces test failure

am confident it will fix the others. Closing this bug report. Collin >From 24fb014092ba8d831c25cd8757a6a738927bb743 Mon Sep 17 00:00:00 2001 Message-ID: <24fb014092ba8d831c25cd8757a6a738927bb743.1757040561.git.collin.fu...@gmail.com> From: Collin Funk Date: Thu, 4 Sep 2025 19:30:00

bug#79300: fold-nbsp test failure

Message-ID: <0114629e0c73b6530f551b645097ff93e4663806.1757046213.git.collin.fu...@gmail.com> From: Collin Funk Date: Thu, 4 Sep 2025 21:13:43 -0700 Subject: [PATCH] maint: prefer c32isspace to iswspace * src/wc.c (wc): Replace call to iswspace with c32isspace. --- src/wc.c | 2 +- 1 file chan

bug#79301: fold-spaces test failure

Bruno Haible writes: > On 2025-08-24 I wrote: >> Today's CI reports a test failure >> FAIL: tests/fold/fold-spaces >> on several systems: >> - Alpine Linux, >> - macOS 13..15, >> - FreeBSD 14. > > Sorry for the incorrect reporting: macOS 13 and 14 failed with a fold-nbsp > failure (bug #7

bug#79300: fold-nbsp test failure

diff: $ git ls-files | grep -E '\.[ch]' | xargs grep -F 'isw' src/wc.c: in_word2 = (! iswspace (wide_char) Okay to change this one to the c32 variant? Collin >From 3a81d44d43b078ee20f1ce2b907c23d0926070b3 Mon Sep 17 00:00:00 2001 Message-ID: <3a81d44d43

bug#79369: seq generates wrong sequences for big numbers

6709 > Marking this as done. Thanks for the fix. Just pushed this tiny patch to fix a 'make syntax-check' failure. Collin >From 8f6430666f38de8950c328ece66a5b5e9ebaaee4 Mon Sep 17 00:00:00 2001 Message-ID: <8f6430666f38de8950c328ece66a5b5e9ebaaee4.1756873108.git.collin.fu...@

bug#79300: fold-nbsp test failure

at the passed char. This patch should do the trick. It fixes it on Solaris 11.4 (cfarm215). I couldn't reproduce the failure seen on the CI machines in my NetBSD 10 VM. But I see no reason why this fix wouldn't work there too. Will push it tomorrow. Collin >From b161b6f6759f2587b82972aee

bug#79366: paste -d option not accepting UTF-8

avidseeker via GNU coreutils Bug Reports writes: > $ paste -d "␞" file1 file2 > > results in ␞ (U+241e) character being converted to � (U+FFFD) > > paste command doesn't seem to support UTF-8 characters. Thanks for the report. This is a long standing issue with more than just paste [1]. I hope

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

Paul Eggert writes: > On 2025-08-28 18:45, yubiao hu wrote: >> * src/df.c (get_dev): Fix potential null pointer dereference >> - Avoid dereferencing stat_file when both device and >> mount_point are NULL >> - Handle allocation failure for cell when mount_point >> is NULL > > Why is this patch

bug#79300: fold-nbsp test failure

Pádraig Brady writes: >> Thanks for the suggestion, but that doesn't work. Any issue with >> skipping based on $host_os for this test and for fold-spaces.sh? >> I was thinking of testing "printf '\u00A0' | ./src/tr -d >> '[:blank:]'" >> but that won't work since 'tr' operates on bytes and U+00A0

bug#79300: fold-nbsp test failure

Pádraig Brady writes: > Perhaps the techniques from tests/wc/wc-nbsp.sh could be used? > Maybe something like: > > check_space() { > char="$1" > # Use -L to determine whether NBSP is printable. > # FreeBSD 11 and OS X treat NBSP as non printable ? > test "$(env printf "=$char=" | wc -L)"

bug#79300: fold-nbsp test failure

Bruno Haible writes: > Collin Funk wrote: >> My initial idea was to check if U+2007 FIGURE SPACE and U+00A0 NO-BREAK >> SPACE are blank using grep. But apparently Solaris grep does not handle >> multibyte characters. Therefore, FIGURE SPACE cannot be checked. :( > >

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

Hi, yubiao hu writes: > Package: coreutils > Version: 9.4 > Severity: normal > > I was trying to build coreutils with ASan, and found a memory leak in expr. > > When running: > expr length "hello" > > Output: > = > ==755058==ERROR:

bug#79300: fold-nbsp test failure

Bruno Haible via GNU coreutils Bug Reports writes: > Today's CI run reports > FAIL: tests/fold/fold-nbsp > on NetBSD 10 and Solaris 11.4. > > The log output in both cases is: > > FAIL: tests/fold/fold-nbsp > == > > --- exp1 2025-08-24 06:57:52.605590760 + > +++

bug#79301: fold-spaces test failure

Bruno Haible via GNU coreutils Bug Reports writes: > Today's CI reports a test failure > FAIL: tests/fold/fold-spaces > on several systems: > - Alpine Linux, > - macOS 13..15, > - FreeBSD 14. > > Here are the relevant parts of the log files. Thanks. On Alpine this is because iswblank in

bug#79299: nproc-quota test failure

Bruno Haible writes: > Collin Funk wrote: >> The CentOS 7 one fails because SCHED_DEADLINE is not defined by >> sched.h. But it is defined in linux/sched.h. The second patch, which is >> for Gnulib, fixed it in my CentOS 7 container. > > This patch would be fine to a

bug#79299: nproc-quota test failure

ntainer. Will let others check before pushing. I don't know much about cgroups and whether CentOS 7 is too old for this test to matter. Collin >From f1839652a52d3fd3e66b92800e41c0a8dbc0d9e0 Mon Sep 17 00:00:00 2001 Message-ID: From: Collin Funk Date: Sun, 24 Aug 2025 02:03:51 -0700 Su

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

Closing this now that the patches are pushed. Thanks for the help Paul and Pádraig. Collin

bug#62385: POSIX behavior of readlink, realpath

Paul Eggert writes: > On 2025-08-03 12:47, Collin Funk wrote: >> How about the wording and formatting of the attatched patch? > > Thanks, looks good. Marking this bug as done since readlink and realpath should now comply with POSIX 2024. If not, we can treat it as a new bug.

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

Vincent Lefevre wrote: > With GNU Coreutils 9.4, both "test -a -a -a" and "test -o -o -o" fail: > > $ export POSIXLY_CORRECT=1 > $ /usr/bin/test -a -a -a ; echo $? > /usr/bin/test: ‘-a’: unary operator expected > 2 > $ /usr/bin/test -o -o -o ; echo $? > /usr/bin/test: ‘-o’: unary operator expect

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

atch to fix it. Otherwise, the patch was good. Thanks! Collin >From c9ae3b553d54a067d880026939de536e6ac39192 Mon Sep 17 00:00:00 2001 Message-ID: From: Collin Funk Date: Thu, 14 Aug 2025 19:43:52 -0700 Subject: [PATCH] maint: avoid syntax-check failure from previous commit * src/tsort.c

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

Pádraig Brady writes: >> I have attached a proposed patch. >> I followed the POSIX recommendation of using the exit status 0 - 124 >> for >> the number of cycles and 125 for program errors (e.g. closing standard >> output). > > -w seems a bit arbitrary to standardize since I only see it in OpenBS

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

Paul Eggert writes: > Come to think 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. Haven't tested the patch. But I do n

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

Collin Funk writes: > However, that means that when POSIXLY_CORRECT is not defined the exit > status is ambiguous as shown in the following example: > > # Input with a cycle. > $ printf 'a b\nb a\n' | ./src/tsort > tsort: -: input contains a loop: &

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

Collin Funk writes: > I'll have a look at implementing this behavior. But figured it was worth > sending on bug-coreutils for tracking like the rest of the missing POSIX > 2024 features. I have attached a proposed patch. I followed the POSIX recommendation of using the exit stat

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

POSIX 2024 added the -w option to tsort. Here is the description: -w Set the exit status to the number of cycles found in the input, or to an implementation-defined maximum if there are more cycles than that maximum. If no cycles are found, the exit status shall

bug#79218: BUG: sudo rm -rf /* removes without --no-preserve-root

Hi, Doctorixx writes: > Hello coreutils maintainers, > > I noticed a potentially dangerous difference in how rm handles the / and /* > patterns. > > Currently: > > $ sudo rm -rf / > rm: it is dangerous to operate recursively on '/' > rm: use --no-preserve-root to override this failsafe > > This

bug#62385: POSIX behavior of readlink, realpath

Pádraig Brady writes: > Logic looks good. > The --help for -E is too wordy I think. > I would squash this in instead. > > thanks! > Padraig > > diff --git a/src/realpath.c b/src/realpath.c > index b06e5e845..1f7882b49 100644 > --- a/src/realpath.c > +++ b/src/realpath.c > @@ -72,11 +72,8 @@ usag

bug#62385: POSIX behavior of readlink, realpath

Collin Funk writes: > 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

bug#76897: id improvements

Nicolas said: > Context: > $ cat /etc/passwd > nicolas:x:1000:2001::/home/nicolas:/bin/bash > claude:x:1000:2002::/home/claude:/bin/zsh > $ cat /etc/group > gnicolas:x:2001: > gclaude:x:2002: > > Test case: > localhost login: claude > $ getent passwd claude > claude::1000:2002::/home/claude:/bin

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#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#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

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#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#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 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

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#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

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#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#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 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

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#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#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#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#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

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#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

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#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

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#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#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#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#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#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#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

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#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#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#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#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#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#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#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"

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#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#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#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#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#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#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#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