* tests/misc/numfmt.pl: Here. This avoids a spurious failure when
/bin/sh is dash (as can happen on Debian systems).
---
tests/misc/numfmt.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/misc/numfmt.pl b/tests/misc/numfmt.pl
index 61917fb..553f68b 100644
---
On 04/25/2013 07:29 AM, Paul Eggert wrote:
On 04/24/2013 02:08 AM, Pádraig Brady wrote:
Bernhard noticed this also:
http://lists.gnu.org/archive/html/coreutils/2013-03/msg00065.html
Thanks, here's a proposed patch. I'll CC: this to Bruno since he's
gettext's maintainer.
From
It happens when building from a bootstrapped git checkout, with the
latest master v8.21-40-g090294b).
This is the exact error:
$ (cd gnulib-tests make check)
...
make[3]: Entering directory
`/storage/home/stefano/src/gnu/coreutils/gnulib-tests'
CC localename.o
cc1: error:
On 01/22/2013 12:23 PM, Pádraig Brady wrote:
On 01/22/2013 10:43 AM, Marcel Böhme wrote:
Dear all,
There is another bug that sneaked into the speed patch of seq on 13.09.12:
560 if (all_digits_p (argv[optind])
561(n_args == 1 || all_digits_p (argv[optind + 1]))
562
On 12/18/2012 12:20 AM, Pádraig Brady wrote:
On 12/17/2012 11:50 AM, Z. Majeed wrote:
Building latest git source in a non-src directory on cygwin win7 with gcc
4.5.3 is broken - a patch follows -
doc/local.mk: doc subdir is not created in build dir - I made it a prereq of
doc/constants.texi
On 12/18/2012 01:48 AM, Pádraig Brady wrote:
So the skip was on purpose and to avoid signal propagation issues seen
on some older systems:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=v8.14-30-g6603e37
This initial failure is worrying, though may be a false positive
due to your
On 12/18/2012 11:20 AM, Pádraig Brady wrote:
[SNIP]
Anyway an explicit `make doc/constants.texi` fails on my system too
(with a non-src build), and so can fail in a larger build
due to ordering of rules.
Since we're manually writing the doc/constants.texi rule anyway,
I prefer to just
this by explicitly checking that the signal handler
is called, which should always happen under normal circumstances.
Reported by Stefano Lattarini on linux-2.6.30-2-686 and bash-4.2.36.
diff --git a/tests/misc/timeout-group.sh b/tests/misc/timeout-group.sh
index 4cefc33..7117abb 100755
On 12/14/2012 06:28 PM, Stefano Lattarini wrote:
While running the coreutils testsuite on my oldish Debian desktop with
a somewhat heavy load and several bleeding-edge tools in PATH, I've
encountered this failure in the 'tests/misc/timeout-group.sh' test.
[SNIP]
I've re-run the test few
On 11/16/2012 02:44 AM, Jim Meyering wrote:
Stefano Lattarini wrote:
Hi Paul, thanks for the quick feedback.
On 11/15/2012 10:03 PM, Paul Eggert wrote:
Thanks, wouldn't the following be a bit cleaner,
since MAINTAINERCLEANFILES contains BUILT_SOURCES?
Possibly yes, but since
In a freshly-cloned repository on Debian with GNU make 3.82 and
gcc 4.7.2.:
$ ./bootstrap ./configure
... [all is ok]
$ make all
...
CC src/echo.o
CCLD src/echo
CC src/env.o
CCLD src/env
CC src/expand.o
CCLD src/expand
CC
On 11/15/2012 07:24 PM, Stefano Lattarini wrote:
In a freshly-cloned repository on Debian with GNU make 3.82 and
gcc 4.7.2.:
$ ./bootstrap ./configure
... [all is ok]
$ make all
...
CC src/echo.o
CCLD src/echo
CC src/env.o
CCLD src/env
On 11/15/2012 07:36 PM, Stefano Lattarini wrote:
The patch below seems to solve the issue. Just let me run a complete
bootstrap to ensure this is the case ...
Yep, it works. But I don't have pushing rights, so someone will have
to apply it for me.
Regards,
Stefano
Hi Paul, thanks for the quick feedback.
On 11/15/2012 10:03 PM, Paul Eggert wrote:
Thanks, wouldn't the following be a bit cleaner,
since MAINTAINERCLEANFILES contains BUILT_SOURCES?
Possibly yes, but since this behaviour is not documented in the Automake
manual, I'd marginally (60-40) prefer
On 11/08/2012 08:44 AM, Paul Eggert wrote:
Ouch, I read your strace output incorrectly: it was napping
for 20 ms, not 2 s. Still, there should be no need to nap
for that long; 1 ms should suffice on your platform.
I installed the following patch to cause the test
to take shorter naps.
tags 12820 + moreinfo
severity 12820 minor
thanks
Hi Paul.
On 11/07/2012 04:46 PM, Paul Eggert wrote:
Can you please run strace ./test-utimens and
let us know the system calls that the failing test
executes?
Sure, here it is:
-*-*-
execve(./test-utimens, [./test-utimens], [/* 89 vars */])
On 11/07/2012 06:06 PM, Stefano Lattarini wrote:
Let's see if I can reproduce the failure with:
$ i=0; while strace -o ut ./test-utimens; do echo RUN $((++i)); done
... Well, I still haven't reproduced it after 47 runs.
Nor after 150 runs. I'll stop trying to reproduce
On 11/07/2012 07:28 PM, Paul Eggert wrote:
On 11/07/2012 09:06 AM, Stefano Lattarini wrote:
stat64(test-utimens.ttmp, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
unlink(test-utimens.ttmp) = 0
nanosleep({0, 2000}, NULL) = 0
open(test-utimens.ttmp, O_WRONLY|O_CREAT
On 10/25/2012 04:25 PM, Bernhard Voelker wrote:
On 10/25/2012 04:08 PM, Jim Meyering wrote:
Bernhard Voelker wrote:
Isn't it Due to lack on the build system, ...?
I.e. coreutils could be built on system A lacking perl,
and then be installed on system B which has perl. The above
text would
Hi Pádraig, Mike.
On 10/24/2012 01:48 AM, Pádraig Brady wrote:
On 10/23/2012 11:27 PM, Mike Frysinger wrote:
if i look at vanilla coreutils-8.20, i see:
Makefile.in:man/uname.1: src/uname.c
which seems to have originated from man/local.mk, but munged:
man/uname.1: src/uname
this
On 10/24/2012 10:25 AM, Andreas Schwab wrote:
Stefano Lattarini stefano.lattar...@gmail.com writes:
There is also a patch available, but it doesn't seem to have
encountered much acceptance unfortunately:
http://lists.gnu.org/archive/html/coreutils/2012-09/msg00132.html
The easiest way
On 10/24/2012 11:31 AM, Stefano Lattarini wrote:
On 10/24/2012 10:54 AM, Jim Meyering wrote:
Pádraig Brady wrote:
`echo warning; touch $manpage`.
Sounds good. I.e., it sounds like we want Stefano's patch, after all.
As you recall, a nice side effect is that we will
no longer distribute
On 10/24/2012 12:38 PM, Stefano Lattarini wrote:
On 10/24/2012 11:31 AM, Stefano Lattarini wrote:
On 10/24/2012 10:54 AM, Jim Meyering wrote:
Pádraig Brady wrote:
`echo warning; touch $manpage`.
Sounds good. I.e., it sounds like we want Stefano's patch, after all.
As you recall, a nice
Severity: minor
OK, this is a minor annoyance rather than a real bug, but I guess
reporting it won't hurt.
In GNU coreutils, the gnulib-provided 'bootstrap' script fails to add
the generated file 'lib/spawn.h' to the .gitignore in 'lib/':
$ ./bootstrap ./configure make
... [all is OK]
$
$ make -j16 check
...
FAIL: df/no-mtab-status
And the same failure (and only that) takes place if the Sun C compiler
is used (version Sun C 5.9 SunOS_i386 Patch 124868-15 2010/08/11).
Regards,
Stefano
On 07/20/2012 04:42 PM, Joachim Schmitz wrote:
First I'd need to get git ported to NonStop, this is on my todolist already.
Appare4ny git install needs Python
AFAIK, only some non-fundamental programs and features in the Git toolbox
need python. Most of git is perfectly usable without
On 07/20/2012 05:19 PM, Joachim Schmitz wrote:
I've been told that git needs python, and in a newer version, for
getting it installed.
That is false; quoting the comments in the git Makefile:
Define NO_PYTHON if you do not want Python scripts or libraries at all.
Haven't verified that yet
On 07/13/2012 04:22 PM, Michael Stummvoll wrote:
Hi,
Thanks for pushing this to bug-coreutils. I never thought about this
for myself.
+ [-]parodd set odd parity (or even parity with '-')\n\
another (and maybe clearer) way could be:
parodd set odd parity
extended names in menus and sectioning are
consistent, and that ordering and presence of nodes in menus and in the
actual text are consistent as well.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
doc/coreutils.texi | 110 ++---
1 file
Below is the produced diagnostic.
Regards,
Stefano
-*-*-*-
coreutils.texi:2207: @itemx must follow @item
coreutils.texi:2705: @itemx must follow @item
coreutils.texi:2855: @itemx must follow @item
coreutils.texi:2863: @itemx must follow @item
coreutils.texi:2876: @itemx must follow @item
Trying to build the latest coreutils from master:
$ make all
...
CC stty.o
stty.c: In function 'main':
stty.c:740:8: error: variable 'speed_was_set' set but not used
[-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors
make[3]: *** [stty.o] Error 1
On 07/01/2012 12:29 AM, Karl Berry wrote:
Hi Stefano,
coreutils.texi:2207: @itemx must follow @item
I imagine the diagnostic is correct.
Sorry if I hasn't been clear, but I meant the CC: to 'texinfo-devel' just
as an FYI to you, not a bug report (otherwise I'd have written to
On 04/21/2012 11:48 AM, Stefano Lattarini wrote:
* configure.ac (AM_INIT_AUTOMAKE): Add the 'ng' option, to ensure that
mainstream Automake is not used by mistake when bootstrapping. Also,
bump the required Automake version from '1.11.1' to '1.11e', which is
the latest (and still development
Hi Jim, thanks for the feedback.
On 05/08/2012 09:57 PM, Jim Meyering wrote:
Stefano Lattarini wrote:
So, OK to apply this patch to a new branch in the coreutils official
repository? Or it's better if I clone the coreutils repo on GitHub
and work there, to have more freedom while
-by: Stefano Lattarini stefano.lattar...@gmail.com
---
I'd like this to be applied to an experimental branch in the coreutils
repository, which will be used to test and experiment with Automake-NG
in a real-world, important, medium-complexity package like GNU coreutils
is.
I hope you'll agree
* bootstrap.conf ($buildreq): Require autoconf 2.64, not 2.62. This is
consistent with what is required by AC_PREREQ in configure.ac.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
bootstrap.conf |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Hi Eric.
On 02/16/2012 04:28 PM, Eric Blake wrote:
You can always use 'rm -rf dummy $file_list' without having to check for
whether $file_list is empty, but yes, that is the primary reasoning why
-f with no options behaves differently than any other case with no options.
FYI: I just opened
Severity: wishlist
[CC:ing bug-automake, so that we won't forget about this issue]
Reference:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10819#40
POSIX will say in a future version that running rm -f with no argument is OK;
we might simplify several automake-generated cleaning rules
On 01/05/2012 02:08 PM, Stefano Lattarini wrote:
On 01/05/2012 01:47 PM, Stefano Lattarini wrote:
[adding bug-automake in CC:]
Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=104367#8
And here is the definitive version of the patch that I'll push by this
evening (to master
7902852607b596d1a341501d1823da826fb4b4ed Mon Sep 17 00:00:00 2001
Message-Id: 7902852607b596d1a341501d1823da826fb4b4ed.1325767602.git.stefano.lattar...@gmail.com
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Thu, 5 Jan 2012 13:41:13 +0100
Subject: [PATCH] parallel-tests: avoid trailing backslashes in make recipes
[adding bug-automake in CC:]
Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10427#8
Hi Paul, thanks for the report and diagnosis.
On 01/05/2012 10:00 AM, Paul Eggert wrote:
The latest coreutils snapshot fail to build
On 01/03/2012 06:10 PM, Jim Meyering wrote:
FYI, here's a
Reference:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10437
On 01/05/2012 03:07 PM, Stefano Lattarini wrote:
Patch coming up soon.
And here it is. I will push by this evening if there is no objection.
Regards,
Stefano
From e3b0e12400f5fa4220fc0aa79dd0989e56def9c6 Mon Sep 17 00:00:00
On 01/05/2012 07:06 PM, Paul Eggert wrote:
On 01/05/12 06:07, Stefano Lattarini wrote:
Which sort of thing exactly? I could find only one place which suffers
of the problem you've pointed out, i.e., the `recheck recheck-html' rules
in lib/am/check.am. Am I missing something?
Sorry
On 01/05/2012 07:24 PM, Stefano Lattarini wrote:
On 01/05/2012 07:06 PM, Paul Eggert wrote:
On 01/05/12 06:07, Stefano Lattarini wrote:
Which sort of thing exactly? I could find only one place which suffers
of the problem you've pointed out, i.e., the `recheck recheck-html' rules
in lib/am
The support for automatic de-ANSI-fication has been deprecated in
automake 1.11.2, and will be removed altogether in automake 1.12.
Also, coreutils does not use the `ansi2knr' option since at least
2003-03-14 (commit b9fa45f2b01d0e395b7ddd845ebabb9528cf3f12 remove
ansi2knr junk, and a few
On Monday 10 October 2011, Jim Meyering wrote:
Stefano Lattarini wrote:
The test failed on my Debian desktop system.
Attached are the log of the failed test, and the (compressed) config.log
generated by configure. Let me know if you need more information.
Regards,
Stefano
On Monday 08 August 2011, Jim Meyering wrote:
Stefano Lattarini wrote:
Date: Thu, 4 Aug 2011 20:48:06 +0200
Subject: [PATCH] tests: complete the renaming framework_failure -
framework_failure_
* tests/init.cfg (framework_failure): Remove, `framework_failure_'
from init.sh should
On Saturday 18 June 2011, Jim Meyering wrote:
Stefano Lattarini wrote:
[Adding bug-coreutils]
Reference:
http://lists.gnu.org/archive/html/automake-patches/2011-06/msg00093.html
On Friday 17 June 2011, Ralf Wildenhues wrote:
I generally like the direction this is taking. The point
.git.stefano.lattar...@gmail.com
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Sat, 18 Jun 2011 13:03:54 +0200
Subject: [PATCH] maint: fix typos in comment in configure.ac
* configure.ac ($MAN): Fix typos in explicative comments.
---
configure.ac |2 +-
1 files changed, 1 insertions
Running make distcheck from the latest git version of autoconf, I get
this error:
... [LOTS OF OUTPUT SNIPPED]
redundant_const
0.12 redundant_const
require_config_h
0.07 require_config_h
require_config_h_first
1.02 require_config_h_first
require_stdio_safer
0.11
On Saturday 18 June 2011, Jim Meyering wrote:
Stefano Lattarini wrote:
...
In order to work with the upcoming new Automake testsuite harness,
coreutils
have two possibilities:
1. move the `shell_or_perl_' subroutine's functionality into a real
acript,
and define
On Saturday 18 June 2011, Stefano Lattarini wrote:
On Saturday 18 June 2011, Jim Meyering wrote:
Stefano Lattarini wrote:
...
In order to work with the upcoming new Automake testsuite harness,
coreutils
have two possibilities:
1. move the `shell_or_perl_' subroutine's
OK, this is just a silly cosmetic issue, but maybe you'd like to know
about it anyway:
$ make THANKS
GENTHANKS
./thanks-gen: THANKS.in: duplicate name: Karl Berry
./thanks-gen: THANKS.in: duplicate name: Karl Heuer
./thanks-gen: THANKS.in: duplicate name: Stéphane Raimbault
$
[Adding bug-coreutils]
Reference:
http://lists.gnu.org/archive/html/automake-patches/2011-06/msg00093.html
On Friday 17 June 2011, Ralf Wildenhues wrote:
I generally like the direction this is taking. The point of best
separation between which code goes into Makefile.in and which into
the
/13/2011 04:24 PM, Stefano Lattarini wrote:
On Monday 13 June 2011, Eric Blake wrote:
Not possible to portably sniff out closed fds; quoting the autoconf manual:
Don't rely on duplicating a closed file descriptor to cause an
error. With Solaris @command{/bin/sh}, when the redirection
/archive/html/bug-autoconf/2011-06/msg00018.html
http://lists.gnu.org/archive/html/bug-coreutils/2011-06/msg00082.html
On Tuesday 14 June 2011, Eric Blake wrote:
On 06/13/2011 04:29 PM, Stefano Lattarini wrote:
If this work, then using a bare `2' *at the end of TESTS_ENVIRONMENT* and
You meant
/gmane.comp.gnu.coreutils.bugs/22488
for lots of discussion. Stefano Lattarini suggested the solution
of putting 92 after the command. Reported by Bruno Haible.
---
tests/check.mk |3 +--
tests/init.sh |4 ++--
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/tests/check.mk b
Hello Jim.
Just a minor nit, since your fix will have to be ported to automake's
`tests/defs' too ...
On Monday 13 June 2011, Jim Meyering wrote:
Bruno Haible wrote:
On HP-UX 11.31, built with cc, coreutils-8.12 gives 3 test suite failures:
FAIL: misc/printf-surprise (exit: 1)
FAIL:
On Monday 13 June 2011, Jim Meyering wrote:
Stefano Lattarini wrote:
Hello Jim.
...
Wouldn't it be simpler, and potentially more correct, to use simply:
warn_ () { eval 'echo $@ 1'$stderr_fileno_; }
With your new implementation, I see this on Debian with bash and dash
Hi Jim. Probably you're totally going to hate me today, but ...
On Monday 13 June 2011, Jim Meyering wrote:
From d987cf87de5e7e597e295914c536bd332c24cc63 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Mon, 13 Jun 2011 18:54:53 +0200
Subject: [PATCH] init.sh: redirect
On Monday 13 June 2011, Stefano Lattarini wrote:
Hi Jim. Probably you're totally going to hate me today, but ...
On Monday 13 June 2011, Jim Meyering wrote:
From d987cf87de5e7e597e295914c536bd332c24cc63 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Mon, 13 Jun
On Monday 13 June 2011, Stefano Lattarini wrote:
On Monday 13 June 2011, Stefano Lattarini wrote:
Hi Jim. Probably you're totally going to hate me today, but ...
On Monday 13 June 2011, Jim Meyering wrote:
From d987cf87de5e7e597e295914c536bd332c24cc63 Mon Sep 17 00:00:00 2001
On Monday 13 June 2011, Eric Blake wrote:
Not possible to portably sniff out closed fds; quoting the autoconf manual:
Don't rely on duplicating a closed file descriptor to cause an
error. With Solaris @command{/bin/sh}, when the redirection fails, the
output goes to the original file
On Tuesday 14 June 2011, Eric Blake wrote:
On 06/13/2011 03:39 PM, Stefano Lattarini wrote:
[3] The $(SHELL), which here we assume is ksh with close-on-exec, does a
fork+exec to execute the test script; thus, when that script begins
its execution, it has the fd 9 closed (d'oh
The log of the failed test is attached. I've not looked into it in any way.
Let me know if you need more information.
Regards,
Stefano
FAIL: ls/stat-free-color (exit: 1)
==
++ initial_cwd_=/home/stefano/src/coreutils/_build_bleeding/tests
++ fail=0
+++
On Tuesday 24 May 2011, Jim Meyering wrote:
Stefano Lattarini wrote:
The log of the failed test is attached. I've not looked into it in any way.
Let me know if you need more information.
Regards,
Stefano
FAIL: ls/stat-free-color (exit: 1
At Friday 11 June 2010, Peng Yu wrote:
I'm trying to cp -MM to -M. But so far I don't have a way to do it.
Would you please let me know what is the correct way to cp from -MM
to -M?
$ cp -r -- -MM/ -- -M
The first `--' stops option processing, and so the second `--' is
interpreted like a
Just a few obsevations on side issues...
Bob Proulx writes:
Rodolfo Borges wrote:
cat EOF ~/.bashrc
function mv() {
local target=${!#}
local dir
if [[ $target =~ '/$' ]]; then
dir=$target
else
dir=$(dirname $target)
fi
test -d $dir ||
At Monday 26 April 2010, Jim Meyering j...@meyering.net wrote:
Using env is the most portable, at the expense
of a fork (compared to bash's command):
env mv $@
Generally, this is true. But Rodolfo was assuming bash as his shell
anyway, and in this case the use of well-estabilished bash
At Monday 26 April 2010, Andreas Schwab sch...@linux-m68k.org wrote:
I think that's needed because otherwise the shell function would
end up calling itself recursively, since it's named `mv' too.
You use command mv for that.
Good point, I forgot about that. And it works for shell
70 matches
Mail list logo
