int c;
+ int c IF_LINT (= EOF);
const char *buffer;
size_t buffer_len;
--
2.46.0
From 9b9763e6a7499d78373fb42bac3dc2ee68a14b69 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?=
Date: Wed, 28 Aug 2024 12:33:17 +0100
Subject: [PATCH] all: fix error checking in gl/lib/xdect
Am 27.08.24 um 23:34 schrieb Paul Eggert:
I'm not seeing that false alarm when building coreutils v9.5 on Ubuntu
24.04 LTS with "./configure --enable-gcc-warnings CC=gcc-14".
What GCC version are you using? If it's not GCC 14, try upgrading. I'm
using gcc-14 (Ubuntu 14-20240412-0ubuntu1) 14.0.
I'm not seeing that false alarm when building coreutils v9.5 on Ubuntu
24.04 LTS with "./configure --enable-gcc-warnings CC=gcc-14".
What GCC version are you using? If it's not GCC 14, try upgrading. I'm
using gcc-14 (Ubuntu 14-20240412-0ubuntu1) 14.0.1 20240412
(experimental) [master r14-9935
Hi,
In function 'canonicalize_filename_mode_stk',
inlined from 'canonicalize_filename_mode' at lib/canonicalize.c:464:18,
inlined from 'get_dev' at src/df.c::26:
lib/canonicalize.c:383:33: error: 'end_idx' may be used uninitializ
On 11/05/2024 10:14, Dan Jacobson wrote:
join should have an option to return an error value in the shell's $?
if any lines are not matched.
Currently the man page doesn't even mention a return value. So it is not
set in stone yet.
Currently one must save -v output in a file then u
join should have an option to return an error value in the shell's $?
if any lines are not matched.
Currently the man page doesn't even mention a return value. So it is not
set in stone yet.
Currently one must save -v output in a file then use test -s do detect
if there were any n
On 02/05/2024 07:16, Nineteendo INC wrote:
coreutils version: stable 9.5 (bottled)
OS version: macOS 13.6.6 (22G630)
`realpath` doesn’t behave correctly for unreadable symlinks:
wannes@Stefans-iMac ~ % ln -s . src
wannes@Stefans-iMac ~ % grealpath -e src/..
/Users
wannes@Stefans-iMac ~ % chmod
coreutils version: stable 9.5 (bottled)
OS version: macOS 13.6.6 (22G630)
`realpath` doesn’t behave correctly for unreadable symlinks:
wannes@Stefans-iMac ~ % ln -s . src
wannes@Stefans-iMac ~ % grealpath -e src/..
/Users
wannes@Stefans-iMac ~ % chmod -h 000 src
wannes@Stefans-iMac ~ % gr
tag 68866 notabug
close 68866
stop
On 2/1/24 04:09, Seungchul Lee wrote:
man page description has following line,
"If no option is specified, -P is assumed."
But in my machine, its default behavior seems -L without any option for pwd.
'man pwd' and 'env pwd --help' also tells:
NOTE: your sh
Hello,
man page description has following line,
"If no option is specified, -P is assumed."
But in my machine, its default behavior seems -L without any option for pwd.
Sincerely yours,
Lee.
tag 68064 notabug
close 68064
stop
On 27/12/2023 17:29, Larry Ploetz wrote:
It seems like there might be a problem with date addition when the base
date is specified as “day Monthname” instead of “Monthname day”, where
the offset is being interpreted as an absolute year value. This may be
locale
It seems like there might be a problem with date addition when the base
date is specified as “day Monthname” instead of “Monthname day”, where
the offset is being interpreted as an absolute year value. This may be
locale-specific.
:bin larry$ locale
LANG="en_US.UTF-8"
LC_COLLATE="en_U
On 14/08/2023 20:02, Bruno Haible wrote:
Compiling a current coreutils on Debian GNU/Hurd from 2022, I get this
compilation error:
CC src/copy.o
../src/copy.c: In function 'set_author':
../src/copy.c:984:15: error: 'MACH_PORT_nullptr' undeclared (first use in this
Compiling a current coreutils on Debian GNU/Hurd from 2022, I get this
compilation error:
CC src/copy.o
../src/copy.c: In function 'set_author':
../src/copy.c:984:15: error: 'MACH_PORT_nullptr' undeclared (first use in this
function); did you mean 'MACH_PORT_
Just creating a bug to track the recent fixes
to read error handling in various coreutils. I.e.:
https://github.com/coreutils/coreutils/commit/9d333aca4 cksum
https://github.com/coreutils/coreutils/commit/0e62ba282 tsort
https://github.com/coreutils/coreutils/commit/5595673d5 numfmt
https
dircolors.
cheers,
Pádraig
From a9bd274616a8d2e99736b498e657cda4e6954f3f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?=
Date: Tue, 28 Mar 2023 14:24:29 +0100
Subject: [PATCH] dircolors: diagnose read errors
* NEWS: Mention the fix.
* src/dircolors.c: Fail upon read error fr
On 28/03/2023 09:54, Paul Eggert wrote:
Thanks for reporting that. I installed the attached to fix it.
Looks good thanks.
Also worth the attached test and NEWS,
which I've pushed.
cheers,
PádraigFrom a4525de1ef593cb3873eb88caa7279eb32669bda Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig
= getline (&line, &buflen, in_stream);
if (line_length < 0)
{
- /* FIXME: detect/handle error here. */
+ if (ferror (in_stream))
+die (EXIT_FAILURE, errno, _("%s: read error"),
+ quotef (input_filenam
Hello
The usual case is:
$ echo "2023-03-27 08:30:00" > dates.txt
$ echo "2023-04-01 12:00:00" >> dates.txt
$ /usr/bin/date -f dates.txt
Mon Mar 27 08:30:00 CEST 2023
Sat Apr 1 12:00:00 CEST 2023
If done on a non existing file, we get:
$ date -f non-existing
/usr/bin/date: non-existing: No su
On 22/02/2023 13:28, Martin Castillo wrote:
Hi,
the info page of cp says
Plain ‘--reflink’ is equivalent to ‘--reflink=when’.
but probably means
Plain ‘--reflink’ is equivalent to ‘--reflink=always’.
Martin Castillo
Already fixed in https://github.com/coreutils/core
Hi,
the info page of cp says
Plain ‘--reflink’ is equivalent to ‘--reflink=when’.
but probably means
Plain ‘--reflink’ is equivalent to ‘--reflink=always’.
Martin Castillo
$ sort --human-numeric-sort -nr
sort: options '-hn' are incompatible
Say instead:
sort: options --human-numeric-sort (-h), and --numeric-sort (-n), are
incompatible.
Else some projects might be delayed by days, as some people need to
email other people to ask...
"Can't blame me. That's not what
tag 60030 notabug
close 60030
stop
On 13/12/2022 02:50, Malin Freeborn wrote:
Hi bug-team,
There's a small error in the date man page. If you search for `%F`
you'll notice the date is summarized as so:
%F full date; like %+4Y-%m-%d
The example shows the `%` sign before the `
Hi bug-team,
There's a small error in the date man page. If you search for `%F`
you'll notice the date is summarized as so:
%F full date; like %+4Y-%m-%d
The example shows the `%` sign before the `+`.
Best,
- Malin
tag 59901 notabug
close 59901
stop
On 08/12/2022 03:44, Ridwan Shariffdeen wrote:
Hi,
Running valgrind on src/split with the following command reports a memory
error. I have attached the valgrind output (i.e. Use of uninitialised value)
I couldn't repro this here, and
`src/split`
On 10/17/22 07:44, Ruslan Kovtun wrote:
According to "do one thing and do it well" and to the fact of '-d/--date'
option existence, `date` should be able to parse its default output in any
locale.
Patches would be welcome. Good luck getting it to work, though. Many
date formats are ambiguous,
$ date -d "$( date )"
date: invalid date ‘Пн 17 окт 2022 17:34:00 EEST’
$ date -d "Mon 17 oct 2022 17:34:00 EEST"
Пн 17 окт 2022 17:34:00 EEST
According to "do one thing and do it well" and to the fact of '-d/--date'
option existence, `date` should be able to parse its default output in any
local
On 9/25/22 07:25, Pádraig Brady wrote:
How about the attached to add a NEWS entry,
and add DS_EMPTY, DS_NONEMPTY enums to make the code easier to read?
Sure, that looks good; thanks.
Oh, I forgot that via code inspection I found a theoretical portability
bug in fts while I was looking into Bu
On 25/09/2022 00:37, Paul Eggert wrote:
I ran into this problem when attempting to recursively
remove a directory in a filesystem on flaky hardware.
Although the underlying readdir syscall failed with errno == EIO,
rm issued no diagnostic about the I/O error.
This looks good.
How about the
I ran into this problem when attempting to recursively
remove a directory in a filesystem on flaky hardware.
Although the underlying readdir syscall failed with errno == EIO,
rm issued no diagnostic about the I/O error.
Without this patch I see this behavior:
$ rm -fr baddir
rm: cannot
Thanks! That solved the issue!
On Tue, Sep 6, 2022 at 3:18 PM Paul Eggert wrote:
> Thanks for the bug report. Please try this Gnulib patch, which should
> appear in the next Coreutils release:
>
>
> https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=84863a1c4dc8cca8fb0f6f670f67779cdd2d543b
Thanks for the bug report. Please try this Gnulib patch, which should
appear in the next Coreutils release:
https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=84863a1c4dc8cca8fb0f6f670f67779cdd2d543b
s building this with the same
arguments on x86_64 and armv7l with glibc 2.27.
Configure line is:
./configure --prefix=/usr/local --libdir=/usr/local/lib
--mandir=/usr/local/share/man --build=i686-cros-linux-gnu
--host=i686-cros-linux-gnu --target=i686-cros-linux-gnu --program-prefix=''
--prog
e, char const *dst_name,
bool return_now = false;
if (x->interactive != I_ALWAYS_NO
- && ! same_file_ok (src_name, &src_sb, dst_dirfd, dst_relname,
+ && ! same_file_ok (src_name, &src_sb, dst_dirfd, drelname,
pathname and return ENOENT.
Instead, the exact same steps work on arch linux 2022.03, which has
coreutils 9.0-2. Note that -x should prevent trying to copy /mnt under
itself; on 2022.03, there is a proper error message for cp -a / /mnt
without -x.
On 4/28/21 16:23, Mark Krenz wrote:
So I'm not sure if this is a problem with coreutils or a change in the
zoneinfo database. Any ideas?
This appears to be a problem in the GNU C library, when its mktime
deciphers the relatively unusual time zone history of Indiana.
I installed the attached
tag 53674 notabug
close 53674
stop
On 2/1/22 03:38, Alexandre Louisdhon wrote:
> Error- tail: unrecognized file system type 0x794c7630 for
> ‘/var/log/syslog’.
Thanks for the report.
That docker image seems to use a quite old coreutils version:
overlayfs - commonly used with Docker cont
Error- tail: unrecognized file system type 0x794c7630 for
‘/var/log/syslog’.
What happened:
First, I git clone a bit bucket repository that contained PHP.
Second, I used git checkout to switch to an existing branch.
Third, I used docker-compose up in my bash terminal.
Finally, I received the
On 15/01/2022 01:09, Paul Eggert wrote:
Thanks for reporting that. This is a duplicate of bug#50784[1], which
was fixed[2] in September.
Perhaps we should generate a new Coreutils soon, since this bug has been
reported three times now.
[1]: https://bugs.gnu.org/50784
[2]:
https://git.savannah.g
Thanks for reporting that. This is a duplicate of bug#50784[1], which
was fixed[2] in September.
Perhaps we should generate a new Coreutils soon, since this bug has been
reported three times now.
[1]: https://bugs.gnu.org/50784
[2]:
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=
Hello,
we found a case, where chmod from coreutils 9.0 fails (exit value 1), while the
one from 8.29 succeeds. (exit value 0)
Unfortunately, no (error) message is given, just the exit value is 0 and 1
respectively.
Here is the example:
== 8.29: fine
>chmod --version
chmod (
ok I appreciate the explanation.
On Wed, 29 Dec 2021 at 20:58, Paul Eggert wrote:
> On 12/29/21 12:01, Martin Rixham wrote:
> > What nonsense. I want to parse source code. ')' is not an uncommon line
> of
> > source code. It should work.
>
> Unfortunately, you're asking for what is in general im
What nonsense. I want to parse source code. ')' is not an uncommon line of
source code. It should work.
On Wed, 29 Dec 2021 at 19:52, Paul Eggert wrote:
> On 12/29/21 08:31, Davide Brini wrote:
> > I think you need to use '+' before the offending token
>
> Yes. That's a GNU extension. If you wan
On 12/29/21 12:01, Martin Rixham wrote:
What nonsense. I want to parse source code. ')' is not an uncommon line of
source code. It should work.
Unfortunately, you're asking for what is in general impossible. If the
left argument of ':' could be any string, then the grammar for 'expr'
would be
On 12/29/21 08:31, Davide Brini wrote:
I think you need to use '+' before the offending token
Yes. That's a GNU extension. If you want to be portable to any POSIX
implementation, you can use this instead:
expr "X(" : '.*' - 1
A similar example is given in the POSIX spec for 'expr':
https:/
On Wed, 29 Dec 2021 12:42:24 +, Martin Rixham
wrote:
> I'm getting an error from the following:
>
> [martin@fedora ~]$ expr ')' : '.*'
> expr: syntax error: unexpected ')'
>
> There also seems to be a similar problem with:
>
&
I'm getting an error from the following:
[martin@fedora ~]$ expr ')' : '.*'
expr: syntax error: unexpected ')'
There also seems to be a similar problem with:
expr '(' : '.*'
Here's the version:
[martin@fedora ~]$ e
On Fri, 26 Nov 2021 18:54:54 +0100
Bernhard Voelker wrote:
> On 11/26/21 13:23, Frank Busse wrote:
> > I tried it several times with checking the timestamps/md5sums of the
> > files but after remounting the stick it doesn't happen anymore?! I
> > guess it was a hiccup somewhere else in the system
On 11/26/21 04:23, Frank Busse wrote:
I
guess it was a hiccup somewhere else in the system, sorry.
Thanks for following up; closing the bug report.
On 11/26/21 13:23, Frank Busse wrote:
> I tried it several times with checking the timestamps/md5sums of the
> files but after remounting the stick it doesn't happen anymore?! I
> guess it was a hiccup somewhere else in the system, sorry.
Perhaps the USB stick was removed from the system before th
On Fri, 26 Nov 2021 12:05:21 +
Chris Elvidge wrote:
> Is your USB stick (V)FAT(32) (or similar) formatted?
It's FAT32.
> > The error is fine but mv deletes /src/foo and keeps mnt/dst/foo,
> > meaning that the data of the new file is lost. Is this the intended
>
On 26/11/2021 11:07 am, Frank Busse wrote:
Hi,
Given two files: an old version of "foo" on a mounted USB stick:
/mnt/dst/foo
and a new version of "foo" in /src/foo on the system's hard drive. When
I do:
sudo mv /src/foo /mnt/dst/foo
I get the following error
Hi,
Given two files: an old version of "foo" on a mounted USB stick:
/mnt/dst/foo
and a new version of "foo" in /src/foo on the system's hard drive. When
I do:
sudo mv /src/foo /mnt/dst/foo
I get the following error:
mv: failed to preserve ownership for
Thanks for your patience and clarification. I was able to get it working
properly with the latest master:
RUN git clone --branch master --single-branch
https://git.savannah.gnu.org/git/coreutils.git \
&& cd coreutils \
&& export FORCE_UNSAFE_CONFIGURE=1 \
&& ./bootstrap \
&& ./co
On 8/17/21 4:48 PM, softwarebugreports via GNU coreutils Bug Reports wrote:
Thank you for the help! I tried using 8002ca7b56acb46b42eeac4a343e112a8ee283cf
and the latest commits from master
You can't combine the latest Coreutils master commit with old Gnulib
commits like 8002ca7b56acb46b42eea
t
apply cleanly
#10 177.2 gnulib/gnulib-tool: *** Stop.
#10 177.2 ./bootstrap: gnulib-tool failed
#10 ERROR: executor failed running [/bin/sh -c git clone --branch v8.32
--single-branch https://git.savannah.gnu.org/git/coreutils.git && cd
coreutils && git clone https:/
On 17/08/2021 16:16, Pádraig Brady wrote:
On 17/08/2021 02:32, softwarebugreports via GNU coreutils Bug Reports wrote:
I receive the following error when using make with coreutils in a alpine based
docker container:
#10 304.5 parse-datetime.tab.c:658:10: fatal error: parse-datetime.tab.h
On 17/08/2021 02:32, softwarebugreports via GNU coreutils Bug Reports wrote:
I receive the following error when using make with coreutils in a alpine based
docker container:
#10 304.0 CC lib/mkdir-p.o
#10 304.1 CC lib/modechange.o
#10 304.1 CC lib/mpsort.o
#10 304.2 CC lib/nproc.o
#10 304.2
I receive the following error when using make with coreutils in a alpine based
docker container:
> #10 304.0 CC lib/mkdir-p.o
> #10 304.1 CC lib/modechange.o
> #10 304.1 CC lib/mpsort.o
> #10 304.2 CC lib/nproc.o
> #10 304.2 CC lib/nstrftime.o
> #10 304.3 CC lib/openat-die.o
old_mode IF_LINT ( = 0);
- mode_t new_mode IF_LINT ( = 0);
- bool ok = true;
- bool chmod_succeeded = false;
+ struct change_status ch;
+ ch.status = CH_NO_STAT;
switch (ent->fts_info)
{
@@ -217,27 +231,23 @@ process_file (FTS *fts, FTSENT *ent)
if (! force_silent)
err
Hi,
I noticed that when running chmod with -v on a dangling symlink the
error message is somewhat random:
> ln -s file-that-does-not-exist lnk
> chmod -w lnk -v
> chmod: cannot operate on dangling symlink 'lnk'
> failed to change mode of 'lnk' from 000
/* The wording of this diagnostic should cover at least two cases:
- the file does not exist, but the parent directory is unwritable
@@ -193,9 +197,9 @@ touch (char const *file)
}
else
{
- if (no_create && errno == ENOENT)
+ i
hello,
touch utility telling weird error on file creation on a immutable/ro dir.
apparently, it does not catch/report the first error (EPERM) but only
the second one (ENOENT), when trying to set the time on the non-existing
file.
regards
roland kletzing
sysadmin
root@s900:/tmp# mkdir /tmp
Well it seems that this might actually be related to timezone database
files. My timezone is America/Indianapolis but I noticed when I set the
timezone to America/New_York or UTC that this problem doesn't happen
$ TZ=America/Indianapolis date -d "now - 9001 days"
date: invalid date ‘now - 9001
Further investigating this problem it appears that at least today it
doesn't like going back past September 26th, 1997. But only when the
time delta is specified in years months or days. You can go back
further if it's specified in total amounts of hours minutes or seconds.
$ date -d "now - 28
I ran the following expecting it to provide me with the date 35 years
ago
date -d "now - 35 years"
Instead I received the error:
date: invalid date ‘now - 35 years’
Testing it further I found that the break point is at 24 years:
$ date --version
date (GNU coreutils) 8.32
Co
Hi Padraig,
On 11/30/20 10:31 PM, Pádraig Brady wrote:
> For my reference, if we were to give explicit diagnosis of the leading '='.
> we would need to update xstrtol_fatal, XARGMATCH, operand2sig, set_fields, ...
I'd also rather keep it like it is, but if we change something:
we could advance pa
On 30/11/2020 17:22, Pádraig Brady wrote:
On 30/11/2020 15:21, 積丹尼 Dan Jacobson wrote:
Well OK, but when and when not to use the "=" is not revealed by the
otherwise detailed error messages. So unless the user checks the manual,
they will never "get it".
If we were to r
On 30/11/2020 15:21, 積丹尼 Dan Jacobson wrote:
Well OK, but when and when not to use the "=" is not revealed by the
otherwise detailed error messages. So unless the user checks the manual,
they will never "get it".
If we were to recognize "-I seconds",
it should ju
Well OK, but when and when not to use the "=" is not revealed by the
otherwise detailed error messages. So unless the user checks the manual,
they will never "get it".
nds' for '--iso-8601'
Valid arguments are:
- 'hours'
- 'minutes'
- 'date'
- 'seconds'
- 'ns'
Try 'date --help' for more information.
Hey, that is a valid argument for --iso-8601. (But not for
Valid arguments are:
- 'hours'
- 'minutes'
- 'date'
- 'seconds'
- 'ns'
Try 'date --help' for more information.
> Hey, that is a valid argument for --iso-8601. (But not for -I, so say
> that instead.)
...
> dat
$ date -I=seconds
date: invalid argument ‘=seconds’ for ‘--iso-8601’
Hey, that is a valid argument for --iso-8601. (But not for -I, so say
that instead.)
Here is a real invalid argument:
$ date --iso-8601=secondsz
date: invalid argument ‘secondsz’ for ‘--iso-8601’
date (GNU coreutils) 8.32
Ruder Laplace wrote:
> Greetings,
>
> I think I catched a bug related to the day-light saving gap:
> *uname -a ; date ; date -d "2020/06/01 10:00:00 +1 hours"*
> Linux 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64
> GNU/Linux
> mié nov 25 10:30:29 CET 2020
> lun jun 1 *12*
Greetings,
I think I catched a bug related to the day-light saving gap:
*uname -a ; date ; date -d "2020/06/01 10:00:00 +1 hours"*
Linux 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64
GNU/Linux
mié nov 25 10:30:29 CET 2020
lun jun 1 *12*:00:00 CEST 2020
As far as I think it
Thanks for reporting your recipe for working around all these problems. I've
installed patches for the problems into coreutils and gnulib and am closing the
bug report.
On 11/21/20 3:45 PM, Chris Elvidge wrote:
git commit -m 'build: update gnulib submodule to latest' gnulib 2>&1 | tee -a
$outf
On 11/21/20 6:37 AM, Chris Elvidge wrote:
parse-datetime.y: In function 'parse_datetime2':
parse-datetime.y:2301:27: error: format '%lld' expects argument of type 'long
long int', but argument 2 has type 'time_t {aka long int}' [-Werror=format=]
That
On 11/21/20 5:17 AM, Pádraig Brady wrote:
The info in https://bugs.gnu.org/44739 must be incorrect,
and we've two counter checks to it now.
Yes, that sounds right. Closing that bug report.
ke.3.txt
Cheers all!!
On 21/11/2020 09:16 pm, Bernhard Voelker wrote:
[adding Paul]
On 11/21/20 8:54 PM, Chris Elvidge wrote:
CC test-nl_langinfo-mt.o
test-nl_langinfo-mt.c: In function 'threadN_func':
test-nl_langinfo-mt.c:185:1: error: no return statement in function
returning n
[adding Paul]
On 11/21/20 8:54 PM, Chris Elvidge wrote:
>CC test-nl_langinfo-mt.o
> test-nl_langinfo-mt.c: In function 'threadN_func':
> test-nl_langinfo-mt.c:185:1: error: no return statement in function
> returning non-void [-Werror=return-type]
> }
>
OK All. Thanks for all the help.
Whether the bison (3.0.2 -> 3.7) upgrade was needed seems to be a moot
point.
Berny's mod to the bootstrap process (adding a step just before
configure 'git clean -xdfq && ./bootstrap') got over the first error.
Akim's mod to lib
n 'parse_datetime2':
> parse-datetime.y:2301:27: error: format '%lld' expects argument of type 'long
> long int', but argument 2 has type 'time_t {aka long int}' [-Werror=format=]
> parse-datetime.y:2301:25: note: in expansion of macro
it -m 'build: update gnulib submodule to latest' gnulib
git clean -xdfq && ./bootstrap | tee -a out_bootstrap.2
./configure TIME_T_32_BIT_OK=yes | tee -a out_configure.1
I've got the output of the second bootstrap run (git clean deleted the
first one, I think) and the conf
Hi all,
> Le 20 nov. 2020 à 16:48, Pádraig Brady a écrit :
>
> See also https://bugs.gnu.org/44739
There, I just read this:
>> I found that I needed to upgrade to Bison v3.7.4 to avoid a build error
>> in stdlib.h where @GNULIB_POSIX_MEMALIGN@ has not been converted by
Still no luck. Same error in parse-datetime.y
Cheers
On 21/11/2020 01:17 pm, Bernhard Voelker wrote:
On 11/20/20 5:38 PM, Chris Elvidge wrote:
Reran the whole thing from git clone etc.
(
git clone git://git.sv.gnu.org/coreutils
cd coreutils
./bootstrap
git submodule foreach git pull origin
Well, that got me a bit further. Thanks.
Now the error from 'make' is:
CC lib/parse-datetime.o
In file included from lib/gettext.h:26:0,
from parse-datetime.y:71:
parse-datetime.y: In function 'parse_datetime2':
parse-datetime.y:2301:27: error: f
On 11/20/20 5:38 PM, Chris Elvidge wrote:
> Reran the whole thing from git clone etc.
> (
> git clone git://git.sv.gnu.org/coreutils
> cd coreutils
> ./bootstrap
> git submodule foreach git pull origin master
> git config --global user.email "celvidge...@gmail.com"
> git config --global user.name "
/lib/parse-datetime.y:555.9-16: syntax error, unexpected identifier,
expecting string
It chokes on `%define api.pure`.
According to NEWS, this syntax was introduced in 2.4 (2008-11-02).
I have tried to install 2.7 on my system, but I can't (because of
portability issues of vasnprintf that wer
e-datetime.y:555.9-16: syntax error, unexpected identifier,
expecting string
It chokes on `%define api.pure`.
According to NEWS, this syntax was introduced in 2.4 (2008-11-02).
I have tried to install 2.7 on my system, but I can't (because of
portability issues of vasnprintf that were not cove
Hi Pádraig,
> Le 20 nov. 2020 à 15:47, Pádraig Brady a écrit :
>
> On 20/11/2020 14:19, Chris Elvidge wrote:
>> I keep getting
>> ./lib/stdlib.h:695:5: error: token "@" is not valid in preprocessor
>> expressions
>> #if @GNULIB_ALIGNED_ALLOC@
>&g
bal user.name "Chris Elvidge"
git commit -m 'build: update gnulib submodule to latest' gnulib
./configure
)
'make' still fails with the same error message(s)
Cheers
On 20/11/2020 03:48 pm, Pádraig Brady wrote:
On 20/11/2020 15:42, Chris Elvidge wrote:
Update
On 20/11/2020 15:42, Chris Elvidge wrote:
Updated to bison 3.7; installed in /usr/local/bin
Unfortunately, still the same error
Logged off/on, disabled /usr/bin/bison and yacc, rebooted.
No go.
Thanks.
Did you rerun bootstrap?
What version was /usr/bin/bison ?
See also https://bugs.gnu.org
Updated to bison 3.7; installed in /usr/local/bin
Unfortunately, still the same error
Logged off/on, disabled /usr/bin/bison and yacc, rebooted.
No go.
Thanks.
On 20/11/2020 02:47 pm, Pádraig Brady wrote:
On 20/11/2020 14:19, Chris Elvidge wrote:
I keep getting
./lib/stdlib.h:695:5: error
On 20/11/2020 14:19, Chris Elvidge wrote:
I keep getting
./lib/stdlib.h:695:5: error: token "@" is not valid in preprocessor
expressions
#if @GNULIB_ALIGNED_ALLOC@
^
./lib/stdlib.h:1059:5: error: token "@" is not valid in preprocessor
expressions
#if @G
I keep getting
./lib/stdlib.h:695:5: error: token "@" is not valid in preprocessor
expressions
#if @GNULIB_ALIGNED_ALLOC@
^
./lib/stdlib.h:1059:5: error: token "@" is not valid in preprocessor
expressions
#if @GNULIB_POSIX_MEMALIGN@
^
when running make in t
On 11/16/20 10:58 AM, Christina Palka via GNU coreutils Bug Reports wrote:
I got the following error when attempting to install GraphClust2 using
Docker on Mac.
tail: unrecognized file system type 0x794c7630 for
‘/home/galaxy/logs/uwsgi.log’. please report this to bug-coreut...@gnu.or
Thanks
* Rich Felker:
> Note that in any case, musl's lchmod/fchmodat is not affected since it
> always refuses to change symlink modes; I did this because I was
> worried that chmod on the magic symlink in /proc might pass through
> not just to the symlink it refers to, but to the symlink target if one
On Wed, Feb 12, 2020 at 08:05:55AM -0500, Rich Felker wrote:
> On Wed, Feb 12, 2020 at 12:50:19PM +0100, Florian Weimer wrote:
> > * Paul Eggert:
> >
> > > On 1/22/20 2:05 PM, Rich Felker wrote:
> > >> I think we're approaching a consensus that glibc should fix this too,
> > >> so then it would ju
On Wed, Feb 12, 2020 at 12:50:19PM +0100, Florian Weimer wrote:
> * Paul Eggert:
>
> > On 1/22/20 2:05 PM, Rich Felker wrote:
> >> I think we're approaching a consensus that glibc should fix this too,
> >> so then it would just be gnulib matching the fix.
> >
> > I installed the attached patch to
* Paul Eggert:
> On 1/22/20 2:05 PM, Rich Felker wrote:
>> I think we're approaching a consensus that glibc should fix this too,
>> so then it would just be gnulib matching the fix.
>
> I installed the attached patch to Gnulib in preparation for the upcoming
> glibc fix. The patch causes fchmodat
1 - 100 of 1062 matches
Mail list logo