Re: Test failures in coreutils-5.3.0 on cygwin
Eric Blake [EMAIL PROTECTED] writes: POSIX requires that a group name that is completely numeric (yes, that is a portable group name) takes preference over a group number. That's awkward. The obvious workaround is to keep prepending 0s until you come up with a name that's not used. But I'd rather not worry about that unless someone actually runs into the problem. At the moment, I'm not on the machine where I noticed all the problems, but off the top of my head, If you can come up with an exact list of problems, preferably with patches, that'd be nice. Is there any program that makes it easy to map between group names and numbers, other than manually trying to parse /etc/group? /etc/group isn't portable. id is usually the best. Is it worth adding more GNU extensions to the id program to accomplish this? It might be, yes (not that I'd like to spend my time implementing it :-). Frankly I didn't follow your examples, though. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Test failures in coreutils-5.3.0 on cygwin
Eric Blake [EMAIL PROTECTED] wrote: ... Also, I noticed some other tests in the suite that were sensitive to group names. At the moment, I'm not on the machine where I noticed all the problems, but off the top of my head, I remember that at least chown/separator was calling `id' directly rather than relying on group-names, and failing when id returned a space-separated name. If it is easy to fix the test, then let's do that. Otherwise, I'd welcome a change that makes it so affected tests are simply skipped when the only selected/found group name contains a space. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Test failures in coreutils-5.3.0 on cygwin
Eric Blake [EMAIL PROTECTED] writes:
http://lists.gnu.org/archive/html/bug-coreutils/2005-01/msg00063.html
Conceivably this problem could occur on Unix too. I installed this
patch to work around it (on Unix, anyway) by using group numbers
rather than names.
2005-01-17 Paul Eggert [EMAIL PROTECTED]
* tests/group-names: Use numeric group ids, not symbolic group names,
since the latter can have shell metacharacters in them (e.g., spaces).
Problem reported by Eric Blake.
* tests/chgrp/basic: Assume groups are numeric, not symbolic.
* tests/chgrp/deref: Likewise.
* tests/chgrp/posix-H: Likewise.
* tests/chgrp/recurse: Likewise.
Index: tests/group-names
===
RCS file: /fetish/cu/tests/group-names,v
retrieving revision 1.3
diff -p -u -r1.3 group-names
--- tests/group-names 23 Jun 2004 15:07:00 - 1.3
+++ tests/group-names 17 Jan 2005 22:37:32 -
@@ -2,7 +2,7 @@
# Set `groups' to a space-separated list of at least two groups of which
# the user is a member.
-groups=${FETISH_GROUPS-`(id -nG || /usr/xpg4/bin/id -nG) 2/dev/null`}
+groups=${FETISH_GROUPS-`(id -G || /usr/xpg4/bin/id -G) 2/dev/null`}
case $groups in
*' '*) ;;
*) cat EOF 12
Index: tests/chgrp/basic
===
RCS file: /fetish/cu/tests/chgrp/basic,v
retrieving revision 1.19
diff -p -u -r1.19 basic
--- tests/chgrp/basic 19 Aug 2004 20:03:48 - 1.19
+++ tests/chgrp/basic 17 Jan 2005 22:37:32 -
@@ -84,7 +84,11 @@ test $VERBOSE = yes set +x
chgrp '' f
ls -c -t f g
-) 21 | sed s/\([ :]\)$g1$/\1G1/;s/\([ :]\)$g2$/\1G2/ actual
+) 21 | sed
+ s/' to .*[^0-9:].*/' to SOMENAME/
+ s/\([ :]\)$g1$/\1G1/
+ s/\([ :]\)$g2$/\1G2/
+ actual
cat \EOF expected
changed group of `f' to G1
@@ -92,7 +96,7 @@ changed group of `f' to G2
ownership of `f' retained
changed group of `f' to G1
group of `f' retained as G1
-changed group of `f' to G2
+changed group of `f' to SOMENAME
changed group of `d/f3' to G2
changed group of `d' to G2
changed group of `d/f3' to G1
Index: tests/chgrp/deref
===
RCS file: /fetish/cu/tests/chgrp/deref,v
retrieving revision 1.9
diff -p -u -r1.9 deref
--- tests/chgrp/deref 23 Jun 2004 15:07:04 - 1.9
+++ tests/chgrp/deref 17 Jan 2005 22:37:32 -
@@ -30,7 +30,7 @@ touch f
ln -s f symlink
chgrp -h $g2 symlink 2 /dev/null
-set _ `ls -l symlink`
+set _ `ls -ln symlink`
g=$5
test $g = $g2 || {
cat EOF 12
@@ -43,25 +43,25 @@ EOF
fail=0
chgrp $g1 f
-set _ `ls -l f`; g=$5; test $g = $g1 || fail=1
+set _ `ls -ln f`; g=$5; test $g = $g1 || fail=1
chgrp -h $g2 symlink || fail=1
-set _ `ls -l f`; g=$5; test $g = $g1 || fail=1
-set _ `ls -l symlink`; g=$5; test $g = $g2 || fail=1
+set _ `ls -ln f`; g=$5; test $g = $g1 || fail=1
+set _ `ls -ln symlink`; g=$5; test $g = $g2 || fail=1
# This should not change the group of f.
chgrp -h $g2 symlink || fail=1
-set _ `ls -l f`; g=$5; test $g = $g1 || fail=1
-set _ `ls -l symlink`; g=$5; test $g = $g2 || fail=1
+set _ `ls -ln f`; g=$5; test $g = $g1 || fail=1
+set _ `ls -ln symlink`; g=$5; test $g = $g2 || fail=1
chgrp $g2 f
-set _ `ls -l f`; g=$5; test $g = $g2 || fail=1
+set _ `ls -ln f`; g=$5; test $g = $g2 || fail=1
# This *should* change the group of f.
# Though note that the diagnostic you'd get with -c is misleading in that
# it says the `group of `symlink'' has been changed.
chgrp --dereference $g1 symlink
-set _ `ls -l f`; g=$5; test $g = $g1 || fail=1
-set _ `ls -l symlink`; g=$5; test $g = $g2 || fail=1
+set _ `ls -ln f`; g=$5; test $g = $g1 || fail=1
+set _ `ls -ln symlink`; g=$5; test $g = $g2 || fail=1
(exit $fail); exit $fail
Index: tests/chgrp/posix-H
===
RCS file: /fetish/cu/tests/chgrp/posix-H,v
retrieving revision 1.3
diff -p -u -r1.3 posix-H
--- tests/chgrp/posix-H 8 Jun 2004 15:25:59 - 1.3
+++ tests/chgrp/posix-H 17 Jan 2005 22:37:32 -
@@ -48,7 +48,7 @@ for i in $changed; do
# Filter out symlinks (entries that end in `s'), since it's not
# possible to change their group/owner information on some systems.
case $i in *s) continue;; esac
- set _ `ls -dg $i`; shift
+ set _ `ls -dgn $i`; shift
group=$3
test $group = $g2 || fail=1
done
@@ -64,7 +64,7 @@ for i in $not_changed; do
# Filter out symlinks (entries that end in `s'), since it's not
# possible to change their group/owner information on some systems.
case $i in *s) continue;; esac
- set _ `ls -dg $i`; shift
+ set _ `ls -dgn $i`; shift
group=$3
test $group = $g1 || fail=1
done
Index: tests/chgrp/recurse
===
RCS file: /fetish/cu/tests/chgrp/recurse,v
retrieving revision 1.4
diff -p -u -r1.4 recurse
--- tests/chgrp/recurse 23
Re: Test failures in coreutils-5.3.0 on cygwin
Eric Blake wrote: Actually, the tarball includes AM_GNU_GETTEXT_VERSION(0.13.1), the latest version of autopoint is 0.14.1, but some of the gettext .m4 files are newer than the 0.14.1 version. To get a good reconf, I had to use `AUTOPOINT=true autoreconf -fiv', skipping autopoint, because autopoint insisted on pulling in older .m4 files which then broke autoconf. Yes. Jim Meyering changed glibc21.m4 in coreutils on 2004-04-18. The consequence is that autopoint doesn't work any more for coreutils. Bruno - it may be time for a new gettext/autopoint release Yes, I agree. with the smarts to not replace .m4 scripts if the replacement would reduce the serial number That's a too flaky heuristic. If a package maintainer has modified some of the .m4 files that gettext uses, there's no way an automated tool could upgrade other m4 files while guaranteeing its proper functioning. Refusing to modify some m4 files, while modifying others, could well lead to worse problems than before. Also, I couldn't find any gettext mailing list archives on the net, to see if this problem has been reported before. The mailing list is archived as part of the bug-gnu-utils archive. Since Google possibly undefined macro: gl_GLIBC21 doesn't reveal any hits, this problem has not been reported before. Bruno ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Test failures in coreutils-5.3.0 on cygwin
According to Jim Meyering on 1/11/2005 10:09 AM: Once I manually patched the corresponding Makefile.ins, I don't get very far into the testsuite (1 of 5 failed under tests/chgrp), see coreutils.check3. I haven't yet had time to figure out how to get any further. As for tests/chgrp/basic, further investigation shows that you are using `ls -c -t f g' to sort the listings of the two files. Did you intend to sort by ctime or by mtime? The failure is that cygwin is listing g as older than f. Unfortunately, the temp files are deleted as part of the test; I tried reproducing the steps of the test in my /tmp: $ touch f $ chown --from=:None -c :root f changed ownership of `f' to :root $ touch f g $ ~/coreutils-5.3.0/src/chgrp None f g $ ~/coreutils-5.3.0/src/chgrp root g $ sleep 1 $ ~/coreutils-5.3.0/src/chgrp None f $ ~/coreutils-5.3.0/src/chgrp '' f $ stat f g File: `f' Size: 0 Blocks: 0 IO Block: 1024 regular empty file Device: d47c93feh/-730033154d Inode: 340645 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1007/ eblake) Gid: ( 513/None) Access: 2005-01-12 06:52:19.42150 -0700 Modify: 2005-01-12 06:52:19.42150 -0700 Change: 2005-01-12 06:51:35.95275 -0700 File: `g' Size: 0 Blocks: 0 IO Block: 1024 regular empty file Device: d47c93feh/-730033154d Inode: 407455 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1007/ eblake) Gid: (0/root) Access: 2005-01-12 06:52:19.42150 -0700 Modify: 2005-01-12 06:52:19.42150 -0700 Change: 2005-01-12 06:52:19.42150 -0700 $ ls -t f g f g $ ls -c f g g f $ ls -c -t f g g f Is there a bug in the cygwin syscalls used by chgrp not changing the ctime like it should? You may want to consider moving the testsuite to an autotest framework from autoconf. That would help in pinpointing some of the bugs, and has better support for keeping all temp files around when a test fails. If you run `make -k check', it will keep going in spite of failures. Nope, even with `make -k check', my run ends in: == 1 of 5 tests failed Please report to bug-coreutils@gnu.org == make[3]: *** [check-TESTS] Error 1 make[3]: Leaving directory `/home/eblake/coreutils-5.3.0/tests/chgrp' make[2]: *** [check-am] Error 2 make[2]: Target `check' not remade because of errors. make[2]: Leaving directory `/home/eblake/coreutils-5.3.0/tests/chgrp' make[1]: *** [check-recursive] Error 1 make[1]: Target `check' not remade because of errors. make[1]: Leaving directory `/home/eblake/coreutils-5.3.0/tests' make: *** [check-recursive] Error 1 make: Target `check' not remade because of errors. Thanks for the report and patch. I've made that change. Note that those patches don't apply because something (your mail client?) converted all TABs to spaces. User error -- I had copied and pasted from my terminal, rather than attaching, which flattened to spaces. One more patch is necessary to account for $(EXEEXT): since `groups' is a script and does not have $(EXEEXT), the .x.1 rule was breaking when it tried to build groups.1. Updating man page groups.1 groups.td/groups.exe: not found help2man: can't get `--help' info from groups.td/groups.exe make: *** [groups.1] Error 127 2005-01-12 Eric Blake [EMAIL PROTECTED] (tiny change) * man/Makefile.am (.x.1): Don't use $(EXEEXT). Also, I noticed that you have both coreutils-5.3.0/tests/tr/repeat-compl.I and coreutils-5.3.0/tests/tr/repeat-Compl.I in the tarball (and the problem still exists in CVS). This breaks in cygwin, which has case insensitive file names (only one of the two files gets unpacked), and is also a violation of the 8.3 file uniqueness naming rules required for porting to djgpp. Please consider renaming files to make coreutils DOS-friendly. -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] --- man/Makefile.am.orig2005-01-12 06:28:49.655875000 -0700 +++ man/Makefile.am 2005-01-12 06:29:13.030875000 -0700 @@ -128,10 +128,10 @@ @rm -f $@ @echo Updating man page $@; \ mkdir $t; \ - (cd $t $(LN_S) ../../src/$(mapped_name)$(EXEEXT) $*$(EXEEXT)); \ + (cd $t $(LN_S) ../../src/$(mapped_name) $*); \ $(PERL) -- $(srcdir)/help2man \ --include=$(srcdir)/$*.x\ - --output=$@ $t/$*$(EXEEXT) + --output=$@ $t/$* @chmod a-w $@ @rm -rf $t ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Test failures in coreutils-5.3.0 on cygwin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 1/12/2005 6:43 AM: autoreconf should work fine. Why are you using -f (--force)? Or -i (--install) for that matter? Using autoreconf (without -f) should work fine. Habit, I guess. You were correct that it worked without flags. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB5TSE84KuGfSFAYARAswWAJwMN9nMT+hIN9K7dEaL1n+drAR9gwCfdEsA raupe6WayZk6sW79gI93o4Q= =Uu5s -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
