Re: Failed tests for gnu coreutils 5.2.1
J.D. Baldwin [EMAIL PROTECTED] writes: Note that neither -n or -G works with Solaris /usr/bin/id Thanks for your bug report. However, that shell script actually tries this command: (id -nG || /usr/xpg4/bin/id -nG) 2/dev/null Does this not work, when run as root on your host? It works for me (on Solaris 9). If I re-run it with /usr/xpg4/bin/id (which does work with -nG) at the head of PATH, I get the same result (skipped no-x test). That will normally happen, unless you set the environment variable NON_ROOT_USERNAME to a reasonable value, as described in the README file for coreutils. If I set FETISH_GROUPS, the test fails: I suspect that this is because the setuidgid program drops supplementary groups, so setting FETISH_GROUPS won't work here. gmake[3]: Entering directory `/opt/src/coreutils-5.2.1/tests/stty' FAIL: row-col-1 Please try the following patch to tests/stty/row-col-1. It's installed in coreutils CVS right now. --- row-col-1 14 May 2003 06:27:45 - 1.8 +++ row-col-1 3 Jan 2005 21:25:13 - 1.10 @@ -11,6 +11,13 @@ fi COLUMNS=80 export COLUMNS +# Make sure we get English-language behavior. +# See the report about a possibly-related Solaris problem by Alexandre Peshansky +# http://lists.gnu.org/archive/html/bug-coreutils/2004-10/msg00035.html. +# Currently stty isn't localized, but it might be in the future. +LC_ALL=C +export LC_ALL + # Make sure there's a tty on stdin. . $srcdir/../input-tty @@ -19,13 +26,13 @@ export COLUMNS tests=' 1 rows_40_columns_80 40_80 -2 rows_0_columns_0 0_0 +2 rows_1_columns_1 1_1 3 rows_40_columns_80 40_80 -4 rows_0 0_80 -5 columns_0 0_0 -6 rows_40 40_0 -7 rows_0 0_0 -8 columns_80 0_80 +4 rows_1 1_80 +5 columns_1 1_1 +6 rows_40 40_1 +7 rows_1 1_1 +8 columns_80 1_80 9 rows_30 30_80 NA LAST NA ' ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
another id -n - plain id change
I installed this:
2005-04-19 Paul Eggert [EMAIL PROTECTED]
* tests/chmod/setgid: Use numeric group ids, not symbolic group names,
since the latter can have shell metacharacters in them (e.g., spaces).
This follows up to the 2005-01-17 patch, which missed this occurrence.
--- setgid.~1.7.~ 2005-04-18 16:27:00 -0700
+++ setgid 2005-04-18 16:34:28 -0700
@@ -36,7 +36,7 @@ chmod g+s d 2 /dev/null ||
# it may happen that when you create a directory, its group isn't one
# to which you belong. When that happens, the above chmod fails. So
# here, upon failure, we try to set the group, then rerun the chmod
command.
-group=${COREUTILS_GROUP-`(id -ng || /usr/xpg4/bin/id -ng) 2/dev/null`}
+group=${COREUTILS_GROUP-`(id -g || /usr/xpg4/bin/id -g) 2/dev/null`}
if test $group; then
chgrp $group d || framework_failure=1
chmod g+s d || framework_failure=1
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cygwin failing tests/mv/mv-special-1
[EMAIL PROTECTED] (Eric Blake) writes:
why not use ${BUILD_SRC_DIR?}/test instead of the shell builtin
test, so that you are guaranteed to have a working `test -e'?
If this turns into a widespread problem (i.e., widespread to other
platforms) that might be worth the hassle of adding the extra
coupling, but for now I'd rather just skip the problematic tests.
Weird - the directory has more permissions than I specified,
including write permissions; and which permissions are displayed by
ls changes seemingly at random.
It sounds like this goes beyond what coreutils can work around.
On a side note, I take it that
:ext:[EMAIL PROTECTED]:/cvsroot/coreutils is not the master
coreutils repository, because it often takes up to 48 hours to see
your patches.
Yes, that's right; it's synced from the development CVS tree, which is
not publicly-accessible.
Is there another public-accessible repository with less delay?
Sorry, no.
However, now the mv-special-1 test is a false positive on cygwin (at least
until the cygwin maintainers fix their buggy rename(2) that currently
converts fifos into regular files, even while preserving the inode if the
rename did not cross devices, as shown below). So mv/mv-special-1
should probably also add a check that mv-null is still a fifo in its new
home.
Thanks for reporting that; I installed the following patch to try to fix this.
2005-04-19 Paul Eggert [EMAIL PROTECTED]
* tests/mv/mv-special-1: Use test -p to test for fifos, rather
than the (incorrect) test -f and the (inadequate) ls. ls is
inadequate because on some hosts a buggy mv will create a file of
the wrong type (problem reported by Eric Blake). Skip this test
if test -p doesn't work.
--- mv-special-114 Apr 2005 20:35:14 - 1.24
+++ mv-special-119 Apr 2005 07:26:18 - 1.25
@@ -27,6 +27,7 @@ mkdir $tmp || framework_failure=1
cd $tmp || framework_failure=1
rm -f $null || framework_failure=1
mknod $null p || framework_failure=1
+test -p $null || framework_failure=1
mkdir -p $dir/a/b/c $dir/d/e/f || framework_failure=1
touch $dir/a/b/c/file1 $dir/d/e/f/file2 || framework_failure=1
@@ -43,11 +44,10 @@ fi
fail=0
mv --verbose $null $dir $other_partition_tmpdir out || fail=1
# Make sure the files are gone.
-test -f $null fail=1
+test -p $null fail=1
test -d $dir fail=1
# Make sure they were moved.
-# Since `test -e' is not portable, use `ls'.
-ls $other_partition_tmpdir/$null /dev/null || fail=1
+test -p $other_partition_tmpdir/$null || fail=1
test -d $other_partition_tmpdir/$dir/a/b/c || fail=1
# POSIX says rename (A, B) can succeed if A and B are on different file
systems,
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cygwin failing tests/mv/mv-special-1
Eric Blake [EMAIL PROTECTED] writes: we might as well dereference symlinks (one of the CANDIDATE_TMP_DIRS could be a cross-device symlink instead of a mount point) Yes, thanks, that makes sense, though I see no reason to worry about this for .. Second, this is coreutils, so we have a reliable test(1) - the comment about `test -e' not being portable is irrelavant. Third, mv-special-1 is not being careful that the named pipe is still a named pipe on the destination. I think these points are addressed by my previous email and patch. I installed the following slightly-more-conservative patch: 2005-04-19 Paul Eggert [EMAIL PROTECTED] * tests/mv/setup (dot_mount_point): Use stat -L, in case the directory is actually a symbolic link. Problem reported by Eric Blake. --- setup 14 Apr 2005 20:35:34 - 1.13 +++ setup 19 Apr 2005 07:36:39 - 1.14 @@ -15,7 +15,7 @@ for d in $CANDIDATE_TMP_DIRS; do # Skip nonexistent directories. test -d $d || continue - d_mount_point=`stat -c %d $d` + d_mount_point=`stat -L -c %d $d` # Same partition? Skip it. test x$d_mount_point = x$dot_mount_point continue ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: testsuite portability nit
Paul Eggert [EMAIL PROTECTED] wrote: Eric Blake [EMAIL PROTECTED] writes: What was wrong with my proposed patch? I had some qualms with it, because it added coupling between the test cases and the rest of the code, by propagating BUILD_SRC_DIR and EXEEXT from the latter to the former. Coupling like that places extra ... Jim may have other opinions, though. Perhaps he'd prefer the approach of the original patch, in which case we should install that instead. I wouldn't have objected to the original patch, but do see that it would introduce the first use of $EXEEXT in a test script. However, there is precedent for using $BUILD_SRC_DIR. And since there are so few tests for install, I think it's a little friendlier to the other-OS crowd not to skip those tests. Who knows... maybe this test will someday help someone developing on a non-Unix-like system to submit a better patch to install.c. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: renamed fetish to coreutils in a few more places
Paul Eggert [EMAIL PROTECTED] wrote: I installed the following patch to remove fetish to coreutils in a few That was overdue. Long ago, when FIleutils, TExtutils, and SH-utils were merging, I put test tarballs in a directory named fetish/, but people noticed that some corporate content-filters made that directory inaccessible to them. Thanks for doing that. more places. The only nontrivial bit here is removing fetish.sf.net from some URL lists; I assume that's obsolete now? Yes. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Build time requirements.
Hello there, I have noticed that source requires the texinfo package (actually makeinfo) in order to successfully compile and install. Identifying this in the build time dependencies may save some others frustration when starting from a fresh HP-UX 11.11 install. Allen +-+ | Allen Suski, IT Systems Analyst | | SCIENTECH, LLC Idaho Falls, ID| | Office 208/524-9233, FAX 208/524-9282 | | Mobile 208/521-8754 | | email: [EMAIL PROTECTED] (@ @) | +--oOO--(_)--OOo--+ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Build time requirements.
Allen Suski [EMAIL PROTECTED] wrote: I have noticed that source requires the texinfo package (actually makeinfo) in order to successfully compile and install. Identifying this in the build time dependencies may save some others frustration when starting from a fresh HP-UX 11.11 install. Are you using HP's make program? It's had a bug that makes it look like makeinfo is required, when in fact the file mod-times and dependencies indicate that it is *not* required. If you use GNU make, you'll find that makeinfo is not required. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
error
Hi, I have this error: Compilador de optimización versión 13.00.9466 para .NET Framework de Microsoft (R) C/C++ (C) Microsoft Corporation 1984-2001. Reservados todos los derechos. AutoExcel.cpp link /nod:libcpmt.lib kernel32.lib mscoree.lib /out:AutoExcel.exe AutoE xcel.obj link: extra operand `mscoree.lib' Try `link --help' for more information. NMAKE : error grave U1077: 'link' : c?digo devuelto '0x1' Stop. cd .. this is a mscoree.lib error or makefile bad instructions? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: error
Hi, I have this error: Compilador de optimización versión 13.00.9466 para .NET Framework de Microsoft (R) C/C++ (C) Microsoft Corporation 1984-2001. Reservados todos los derechos. AutoExcel.cpp link /nod:libcpmt.lib kernel32.lib mscoree.lib /out:AutoExcel.exe AutoE xcel.obj link: extra operand `mscoree.lib' Try `link --help' for more information. NMAKE : error grave U1077: 'link' : c?digo devuelto '0x1' Stop. cd .. this is a mscoree.lib error or makefile bad instructions? It looks like your PATH is picking up a different version of a file named link.exe (a POSIX-compliant link from coreutils - do you have something like cygwin or mingw installed?) than what your nmake file was expecting (a helper application with a poorly chosen name related to Microsoft's compiler, but when has POSIX naming conventions ever stopped Microsoft from making bad decisions). I doubt the coreutils list can give you any more help than to suggest that you change your PATH environment variable so that nmake finds Microsoft's link like it was expecting. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
