Re: df command should suppress duplicates
On 12/18/2012 12:32 AM, Pádraig Brady wrote: On 12/07/2012 08:48 PM, Bernhard Voelker wrote: http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=10d35b43 FYI, there seem to be issues with this? https://bugzilla.redhat.com/show_bug.cgi?id=887763 Hi Padraig, in the upstream patch, the rootfs doesn't make it into the deduplication list. Regarding rpc_pipefs: well, it is in /proc/mounts but it doesn't seem to be mounted (otherwise it would have a different device number). Could it be that rpc_pipefs was mounted in early boot, and when /dev/sda8 became the new /, it was not mounted again, and is therefore shadowed? Have a nice day, Berny
Re: numfmt (=print 'human' sizes) updates
Hello, Attached is a first shot at documenting 'numfmt' . Comments are welcomed, -gordon numfmt_doc.patch.gz Description: GNU Zip compressed data
bug#13210: [PATCH] maint: cygwin build broken
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 That seems a little hacky, for what seems like an automake bug. Maybe this one is the culprit? http://git.sv.gnu.org/gitweb/?p=automake.git;a=commit;h=v1.11-328-ge87c030 Nope, that change had been later reverted, before any stable release: http://git.sv.gnu.org/gitweb/?p=automake.git;a=commit;h=v1.11-512-g40c3432 I use automake-1.11.6 and the coreutils configured min version is 1.11.2. Specifically I'm not impacted as I have this in Makefile: $(srcdir)/doc/version.texi: $(srcdir)/doc/stamp-vti $(srcdir)/doc/stamp-vti: doc/coreutils.texi $(top_srcdir)/configure test -f doc/$(am__dirstamp) || $(MAKE) $(AM_MAKEFLAGS) doc/$(am__dirstamp) ... This rules is there also for makefiles generated by Automake 1.12.x. And the issue here is really not Automake's fault; the problem really likes in the coreutil's build system, since the declaration: doc/constants.texi: $(top_srcdir)/src/tail.c $(top_srcdir)/src/shred.c is hand-written in 'doc/local.mk', and is not provided by Automake. So what suggested by the OP is not a workaround, but a fix -- and it seems a correct fix to me (albeit a little abusing of Automake's internal). BTW, Steffano, how can I see what release the above commit is included in? No one :-) Only minor versions seem to be tagged? How so? I see: http://git.savannah.gnu.org/gitweb/?p=automake.git;a=commit;h=v1.12 I dislike dependency creep so am open to a workaround as long as we know what's going on. See above. HTH, Stefano
bug#13185: Test case 'misc/timeout-group' failed
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 shell or something. What versions of dash, bash, kernel do you have there? $ bash --version GNU bash, version 4.2.36(2)-release (i686-pc-linux-gnu) $ dpkg -l dash | sed -n '$p' ii dash 0.5.7-3 i386 POSIX-compliant shell $ uname -rsv Linux 2.6.30-2-686 #1 SMP Sat Sep 26 01:16:22 UTC 2009 I can't reproduce at all here with any shell, though you might have older versions. What is your system /bin/sh, dash or bash? Bash. But the affected coreutils testsuite run was done with a more bleeding-edge version of bash, explicitly selected as SHELL (and CONFIG_SHELL). Note you can force a particular SHELL as follows, and it would be interesting to see if the issue affected all shells. The fact is that I haven't been able to reproduce the issue after the first failure. So it won't be easy to ensure whether it has been fixed... make check TESTS='tests/misc/timeout-group.sh' SUBDIRS=. VERBOSE=yes SHELL=bash Hopefully we can come up with a skip for this case too. thanks, Pádraig. Regards, Stefano
bug#13210: [PATCH] maint: cygwin build broken
On 12/18/2012 08:58 AM, Stefano Lattarini wrote:
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
That seems a little hacky, for what seems like an automake bug.
Maybe this one is the culprit?
http://git.sv.gnu.org/gitweb/?p=automake.git;a=commit;h=v1.11-328-ge87c030
Nope, that change had been later reverted, before any stable release:
http://git.sv.gnu.org/gitweb/?p=automake.git;a=commit;h=v1.11-512-g40c3432
I use automake-1.11.6 and the coreutils configured min version is 1.11.2.
Specifically I'm not impacted as I have this in Makefile:
$(srcdir)/doc/version.texi: $(srcdir)/doc/stamp-vti
$(srcdir)/doc/stamp-vti: doc/coreutils.texi $(top_srcdir)/configure
test -f doc/$(am__dirstamp) || $(MAKE) $(AM_MAKEFLAGS)
doc/$(am__dirstamp)
...
This rules is there also for makefiles generated by Automake 1.12.x.
And the issue here is really not Automake's fault; the problem really likes in
the coreutil's build system, since the declaration:
doc/constants.texi: $(top_srcdir)/src/tail.c $(top_srcdir)/src/shred.c
is hand-written in 'doc/local.mk', and is not provided by Automake.
So what suggested by the OP is not a workaround, but a fix -- and it
seems a correct fix to me (albeit a little abusing of Automake's
internal).
I misread the above rule last night, and thought Zartaj's fix
to a broken coreutils.info build was to piggy back on the
working constants.texi build. In general it's best to send
error messages along with a patch like this so that reviewers
can follow the same train of thought.
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 add in the MKDIR_P which is the technique we
use elsewhere in coreutils.
BTW, Steffano, how can I see what release the above commit
is included in?
No one :-)
Only minor versions seem to be tagged?
How so? I see:
http://git.savannah.gnu.org/gitweb/?p=automake.git;a=commit;h=v1.12
I was looking for a tag at each release. 1.11.6 etc.
They weren't done for the 1.11 series but they are in place
since 1.12, for example:
http://git.savannah.gnu.org/gitweb/?p=automake.git;a=commit;h=v1.12.5
There's probably little need to retag older releases,
so it's fine going forward.
I dislike dependency creep so am open to a workaround
as long as we know what's going on.
See above.
Thanks a lot for looking at this, and sorry for misreading
the rule last night, I shouldn't have bothered you at all,
with this now obvious issue.
It's good to know we could rely on am__dirstamp in future if needed.
Zartaj I'll apply the following in your name soon.
thanks!
Pádraig.
commit 860307bde02e12700e8a08daf3536801e86e8da8
Author: Zartaj Majeed zmaj...@sbcglobal.net
Date: Tue Dec 18 09:50:50 2012 +
build: fix cygwin build issues
* doc/local.mk (doc/constants.texi): Ensure the doc directory
is present which is needed when doing a non source dir build,
when the doc/constants.texi target is built before other doc targets.
* src/local.mk: Add $(EXEEXT) to the make-prime-list calls.
diff --git a/doc/local.mk b/doc/local.mk
index 585faf0..ad25528 100644
--- a/doc/local.mk
+++ b/doc/local.mk
@@ -36,6 +36,7 @@ AM_MAKEINFOFLAGS = --no-split
doc/constants.texi: $(top_srcdir)/src/tail.c $(top_srcdir)/src/shred.c
$(AM_V_GEN)LC_ALL=C; export LC_ALL; \
+ $(MKDIR_P) doc \
{ sed -n -e 's/^#define \(DEFAULT_MAX[_A-Z]*\) \(.*\)/@set \1 \2/p' \
$(top_srcdir)/src/tail.c \
sed -n -e \
diff --git a/src/local.mk b/src/local.mk
index ead3b8b..66028c9 100644
--- a/src/local.mk
+++ b/src/local.mk
@@ -387,9 +387,9 @@ src/dircolors.h: src/dcgen src/dircolors.hin
# known ints (currently 128-bit).
BUILT_SOURCES += $(top_srcdir)/src/primes.h
$(top_srcdir)/src/primes.h:
- $(MAKE) src/make-prime-list
+ $(MAKE) src/make-prime-list$(EXEEXT)
$(AM_V_GEN)rm -f $@ $@-t
- $(AM_V_at)src/make-prime-list 5000 $@-t
+ $(AM_V_at)src/make-prime-list$(EXEEXT) 5000 $@-t
$(AM_V_at)chmod a-w $@-t
$(AM_V_at)mv $@-t $@
bug#13210: [PATCH] maint: cygwin build broken
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 add in the MKDIR_P which is the technique we use elsewhere in coreutils. Yeah, but is a simpler and safer idiom. Only minor versions seem to be tagged? How so? I see: http://git.savannah.gnu.org/gitweb/?p=automake.git;a=commit;h=v1.12 I was looking for a tag at each release. 1.11.6 etc. http://git.savannah.gnu.org/cgit/automake.git/tag/?id=v1.11.6 http://git.savannah.gnu.org/cgit/automake.git/tag/?id=v1.11.5 http://git.savannah.gnu.org/cgit/automake.git/tag/?id=v1.11.4 etc ;-) They weren't done for the 1.11 series but they are in place since 1.12, for example: http://git.savannah.gnu.org/gitweb/?p=automake.git;a=commit;h=v1.12.5 There's probably little need to retag older releases, so it's fine going forward. [SNIP] It's good to know we could rely on am__dirstamp in future if needed. Actually, that is an automake internal (as hinted by the 'am__' prefix), and should not be relied upon if at all possible (like it was in this case). Best regards, and HTH, Stefano
bug#13185: Test case 'misc/timeout-group' failed
On 12/18/2012 09:45 AM, Stefano Lattarini wrote: 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 shell or something. What versions of dash, bash, kernel do you have there? $ bash --version GNU bash, version 4.2.36(2)-release (i686-pc-linux-gnu) $ dpkg -l dash | sed -n '$p' ii dash 0.5.7-3 i386 POSIX-compliant shell $ uname -rsv Linux 2.6.30-2-686 #1 SMP Sat Sep 26 01:16:22 UTC 2009 I can't reproduce at all here with any shell, though you might have older versions. What is your system /bin/sh, dash or bash? Bash. But the affected coreutils testsuite run was done with a more bleeding-edge version of bash, explicitly selected as SHELL (and CONFIG_SHELL). Note you can force a particular SHELL as follows, and it would be interesting to see if the issue affected all shells. The fact is that I haven't been able to reproduce the issue after the first failure. So it won't be easy to ensure whether it has been fixed... make check TESTS='tests/misc/timeout-group.sh' SUBDIRS=. VERBOSE=yes SHELL=bash Hopefully we can come up with a skip for this case too. I noticed a possible race in the test script. So I'll apply this soon. thanks, Pádraig. commit 09f72d285514a91495960ea3b0570251eed415b0 Author: Pádraig Brady p...@draigbrady.com Date: Tue Dec 18 13:06:15 2012 + tests: avoid a race in timeout-group.sh * tests/misc/timeout-group.sh: The kernel might possibly delay signal propagation to timeout.cmd long enough, that it exits normally without running the signal handler (as sleep will be in the same process group and so get the signal too). So avoid 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 --- a/tests/misc/timeout-group.sh +++ b/tests/misc/timeout-group.sh @@ -34,7 +34,11 @@ cat timeout.cmd \EOF #!/bin/sh trap 'touch int.received; exit' INT touch timeout.running -sleep $1 +count=$1 +until test -e int.received || test $count = 0; do + sleep 1 + count=$(expr $count - 1) +done EOF chmod a+x timeout.cmd
bug#13185: Test case 'misc/timeout-group' failed
On 12/18/2012 02:18 PM, Pádraig Brady wrote: I noticed a possible race in the test script. So I'll apply this soon. thanks, Pádraig. commit 09f72d285514a91495960ea3b0570251eed415b0 Author: Pádraig Brady p...@draigbrady.com Date: Tue Dec 18 13:06:15 2012 + tests: avoid a race in timeout-group.sh * tests/misc/timeout-group.sh: The kernel might possibly delay signal propagation to timeout.cmd long enough, that it exits normally without running the signal handler (as sleep will be in the same process group and so get the signal too). So avoid 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 --- a/tests/misc/timeout-group.sh +++ b/tests/misc/timeout-group.sh @@ -34,7 +34,11 @@ cat timeout.cmd \EOF #!/bin/sh trap 'touch int.received; exit' INT touch timeout.running -sleep $1 +count=$1 +until test -e int.received || test $count = 0; do + sleep 1 + count=$(expr $count - 1) +done EOF chmod a+x timeout.cmd Seems sensible to me. Let's hope it works; I'll re-open this report if I ever stumble into this problem again. Thanks, Stefano
