Re: cat in locale ru_RU.utf8 or this is the bash issue?

2005-01-12 Thread Andreas Schwab
Peter Volkov Alexandrovich [EMAIL PROTECTED] writes:

 The last question I have, where can I download coreutils-5.3.0? Or this
 is the future release?

See
http://lists.gnu.org/archive/html/coreutils-announce/2004-03/msg1.html.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.


___
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

2005-01-12 Thread Bruno Haible
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

2005-01-12 Thread Eric Blake
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

2005-01-12 Thread Eric Blake
-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


Re: Test report coreutils-5.3.0 on Solaris 7

2005-01-12 Thread Jim Meyering
Eric Blake [EMAIL PROTECTED] wrote:
 I have access to an old Solaris 7 box at work, which has gcc 2.8.1.  When
 compiled with CFLAGS='', all non-root tests pass or are skipped.  But with
 the default CFLAGS='-g -O2', gcc miscompiles putchar() (basically, it
 replaces '\n' with '\0').  This breaks, among other things, the `yes'
 executable, and led to a runaway process in the testsuite that consumed my
 entire disk quota.  A truss log of a stripped-down yes.c is attached, to
 show how putchar() is miscompiled when optimized.  Is it worth putting a
 workaround into coreutils to accomodate this old platform/gcc combination,
 or should I just try again using the system cc or else upgrading gcc to
 the 3.x series?

Thanks for the report.
gcc-3.0 has been out for over 3 years, so I think
it's not worth much trouble to work around that bug.

But if you're interested, an autoconf run-test is
probably the way to go.  It'd make the configure
script detect the problem and exit nonzero.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils