Re: make check problems with coreutils 7.2 and earlier

2009-04-24 Thread Jim Meyering 
Erik Auerswald wrote:
 On Fri, Apr 24, 2009 at 07:26:45AM +0200, Jim Meyering wrote:
 Tim Mooney wrote:

  ./configure --prefix=/local/gnu --exec-prefix=/local/gnu --build 
  x86_64-sun-solaris2.10 --sysconfdir=/etc/local/gnu 
  --libdir=/local/gnu/lib/64 --mandir=/local/gnu/share/man 
  --infodir=/local/gnu/share/info --localstatedir=/var/local/gnu 
  --disable-nls

  checking for a BSD-compatible install... /local/gnu/bin/ginstall -c
  checking whether build environment is sane... yes

 Considering all of the programs from /usr/xpg4/bin mentioned
 in that output, I suspect you have an unusual PATH.
 What is your PATH?

 Just for info: the /usr/xpg4/bin directory is one of several to make
 Solaris standards compliant. You can use different binary dirs to have
 compliance to different versions of the standards.

 Sorry, I don't have access to a Solaris machine right now, so I can't
 check all the details.

Thanks, I have long experience with Solaris' /usr/xpg4/bin.
I don't expect that there's anything wrong with using those
tools at all, and confirmed that coreutils-7.2 built and passed
tests with /usr/xpg4/bin first in the shell's search path.

However, it is unusual enough to put that directory so early
in ones path that I suspect there might be something else
unusual about Tim's PATH.


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

Re: make check problems with coreutils 7.2 and earlier

2009-04-24 Thread Erik Auerswald 
Hello Jim,

On Fri, Apr 24, 2009 at 07:26:45AM +0200, Jim Meyering wrote:
 Tim Mooney wrote:
 
  ./configure --prefix=/local/gnu --exec-prefix=/local/gnu --build 
  x86_64-sun-solaris2.10 --sysconfdir=/etc/local/gnu 
  --libdir=/local/gnu/lib/64 --mandir=/local/gnu/share/man 
  --infodir=/local/gnu/share/info --localstatedir=/var/local/gnu --disable-nls
 
  checking for a BSD-compatible install... /local/gnu/bin/ginstall -c
  checking whether build environment is sane... yes
 
 Considering all of the programs from /usr/xpg4/bin mentioned
 in that output, I suspect you have an unusual PATH.
 What is your PATH?

Just for info: the /usr/xpg4/bin directory is one of several to make
Solaris standards compliant. You can use different binary dirs to have
compliance to different versions of the standards.

Sorry, I don't have access to a Solaris machine right now, so I can't
check all the details.

Best regards,
Erik
-- 
But if you assume a bomb as small as the non-functioning space in a
wristwatch can blow up an airplane, you've got problems far bigger than
one particular brand of wristwatch.
-- Bruce Schneier


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

Re: make check problems with coreutils 7.2 and earlier

2009-04-24 Thread Tim Mooney 

In regard to: Re: make check problems with coreutils 7.2 and earlier, Jim...:


Considering all of the programs from /usr/xpg4/bin mentioned
in that output, I suspect you have an unusual PATH.
What is your PATH?


/local/bin:/local/sbin:/local/krb5/bin:/local/krb5/sbin:/usr/j2se/bin:/opt/SUNWspro/bin:/usr/xpg4/bin:/usr/bin:/usr/ccs/bin:/usr/sbin:/sbin:/usr/sadm/bin:/usr/ucb:/usr/games:/local/gnu/bin:/faculty/ndsu/mooney/bin:/local/tex/bin:/local/bin/X11:/usr/X11/bin:/usr/openwin/bin:/usr/dt/bin:/local/gnu/bin/X11:/opt/openoffice.org3/program:.


It might be useful also to add an echo PATH: $PATH to one of the
tests and check the .log file to see if that prints anything different.


Ok, did that with misc/help-version, and the PATH is exactly the same
as shown above:

FAIL: misc/help-version.log (exit: 1)
=

+ test x/local/gnu/bin/bash = x
+ export SHELL
+ . ./test-lib.sh
++ unset function_test
++ eval 'function_test() { return 11; }; function_test'
+++ function_test
+++ return 11
++ test 11 '!=' 11
+++ pwd
++ test_dir_=/local/src/RPM/BUILD/coreutils-7.2/tests
+++ this_test_
+++ echo ././misc/help-version
+++ sed 's,.*/,,'
++ this_test=help-version
+++ /local/src/RPM/BUILD/coreutils-7.2/src/mktemp -d --tmp=/local/src/RPM/BUILD/
coreutils-7.2/tests cu-help-version.XX
++ t_=/local/src/RPM/BUILD/coreutils-7.2/tests/cu-help-version.29Q48d3pLw
++ trap remove_tmp_ 0
++ trap 'Exit $?' 1 2 13 15
++ cd /local/src/RPM/BUILD/coreutils-7.2/tests/cu-help-version.29Q48d3pLw
++ diff --version
++ grep GNU
++ cmp --version
++ grep GNU
+ echo 'Start of misc/help-version, PATH: /local/bin:/local/sbin:/local/krb5/bin
:/local/krb5/sbin:/usr/j2se/bin:/opt/SUNWspro/bin:/usr/xpg4/bin:/usr/bin:/usr/cc
s/bin:/usr/sbin:/sbin:/usr/sadm/bin:/usr/ucb:/usr/games:/local/gnu/bin:/faculty/
ndsu/mooney/bin:/local/tex/bin:/local/bin/X11:/usr/X11/bin:/usr/openwin/bin:/usr
/dt/bin:/local/gnu/bin/X11:/opt/openoffice.org3/program:.'
Start of misc/help-version, PATH: /local/bin:/local/sbin:/local/krb5/bin:/local/
krb5/sbin:/usr/j2se/bin:/opt/SUNWspro/bin:/usr/xpg4/bin:/usr/bin:/usr/ccs/bin:/u
sr/sbin:/sbin:/usr/sadm/bin:/usr/ucb:/usr/games:/local/gnu/bin:/faculty/ndsu/moo
ney/bin:/local/tex/bin:/local/bin/X11:/usr/X11/bin:/usr/openwin/bin:/usr/dt/bin:
/local/gnu/bin/X11:/opt/openoffice.org3/program:.
+ expected_failure_status_nohup=127
+ expected_failure_status_timeout=125
+ expected_failure_status_printenv=2
+ expected_failure_status_tty=3
+ expected_failure_status_sort=2
+ expected_failure_status_expr=3
+ expected_failure_status_lbracket=2
+ expected_failure_status_dir=2
+ expected_failure_status_ls=2
+ expected_failure_status_vdir=2


[remaining output elided]

Even if I modify my environment so that xpg4 is not in my PATH, I get the
same results.

Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing  Infrastructure  701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164


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

Re: make check problems with coreutils 7.2 and earlier

2009-04-23 Thread Jim Meyering 
Tim Mooney wrote:
 In regard to: Re: make check problems with coreutils 7.2 and earlier, Jim...:
 Thanks for the report.
 The tests are designed always to set PATH to make
 your shell use the just-built tools.

 If that's not happening for you, either the tool (yes) wasn't built
 or your shell is not honoring the PATH settings in the TESTS_ENVIRONMENT
 variable, as set in tests/check.mk.  I suspect the latter.
 It'd be useful to know which shell configure chose for you.
 configure does try to find a sufficiently functional shell,
 but perhaps your system has managed to trick it.

 Please send (to this same list) the output of running your
 configure command, and the output from running make check.

 Sure, included below.  Note that I use locally-compiled
 /local/gnu/bin/bash (4.0.10) as my shell, and I have seen occassional
 strage behavior with configure from some other packages in the past
 because it selects /bin/bash (3.00.16), but even if I set
 CONFIG_SHELL=/local/gnu/bin/bash and export and configure, I still get
 the same behavior.

Thanks.
That seems to rule out bash as the cause.

 ./configure --prefix=/local/gnu --exec-prefix=/local/gnu --build 
 x86_64-sun-solaris2.10 --sysconfdir=/etc/local/gnu --libdir=/local/gnu/lib/64 
 --mandir=/local/gnu/share/man --infodir=/local/gnu/share/info 
 --localstatedir=/var/local/gnu --disable-nls

 checking for a BSD-compatible install... /local/gnu/bin/ginstall -c
 checking whether build environment is sane... yes

Considering all of the programs from /usr/xpg4/bin mentioned
in that output, I suspect you have an unusual PATH.
What is your PATH?

It might be useful also to add an echo PATH: $PATH to one of the
tests and check the .log file to see if that prints anything different.

 checking for a thread-safe mkdir -p... build-aux/install-sh -c -d
 checking for gawk... no
 checking for mawk... no
 checking for nawk... nawk
 checking whether make sets $(MAKE)... yes
...


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

Re: make check problems with coreutils 7.2 and earlier

2009-04-18 Thread Jim Meyering 
Tim Mooney wrote:
 [I'm not subscribed to bug-coretuils, please Cc: me on any relevant
 replies]
 I'm building coreutils on x86_64-sun-solaris2.10, with the Sun Studio 12
 and/or Express compilers.  I'm building in 64 bit mode.  Everything builds
 just fine, but before I finish packaging the software I always run make
 check, to see what problems might turn up and how make check from one
 version of the software differs from make check in previous versions.

 I haven't been able to successfully use make check with coreutils in
 a while.  The problem appears to be that several of the tests are
 performed without the correct PATH, because instead of getting the
 version of the program that was compiled in src/, it's getting the version
 of a particular command that's part of the OS.  This is especially
 problematic when testing yes.  The Solaris version of yes doesn't
 support any of the command line arguments that the tests try, so the
 tests essentially hang while Solaris' yes loops continuously outputting
 things like --help.

Thanks for the report.
The tests are designed always to set PATH to make
your shell use the just-built tools.

If that's not happening for you, either the tool (yes) wasn't built
or your shell is not honoring the PATH settings in the TESTS_ENVIRONMENT
variable, as set in tests/check.mk.  I suspect the latter.
It'd be useful to know which shell configure chose for you.
configure does try to find a sufficiently functional shell,
but perhaps your system has managed to trick it.

Please send (to this same list) the output of running your
configure command, and the output from running make check.

 I'm configuring the software like this

   ./configure --prefix=/local/gnu --exec-prefix=/local/gnu \
 --build x86_64-sun-solaris2.10 \
 --sysconfdir=/etc/local/gnu --libdir=/local/gnu/lib/64 \
 --mandir=/local/gnu/share/man --infodir=/local/gnu/share/info \
 --localstatedir=/var/local/gnu \
 --disable-nls

 and then doing

 gmake
 gmake check VERBOSE=yes

 (gmake is GNU make 3.81).

 I've checked the mailing list archives and I don't see any recent reports
 of this issue, though, and I would think others would have run into the
 same thing.  Is this a known issue, or should I investigate further?

We've seen similar reports, but not recently.  Previous reports have been
on rather old systems, with an inadequate /bin/sh and where configure
failed to find a better shell.

 Also, the README that comes with coreutils has a section on Reporting
 bugs and what you should do when reporting them, but it doesn't actually

That paragraph requests that you send in more details ;-)

IMPORTANT: if you take the time to report a test failure,
please be sure to include the output of running `make check'
in verbose mode for each failing test.  For example,
if the test that fails is tests/misc/df, then you would
run this command:

  (cd tests  make check TESTS=misc/df VERBOSE=yes)  log 21

For some tests, you can get even more detail by adding DEBUG=yes.
Then include the contents of the file `log' in your bug report.


 include the address to report them to.  People familiar with other GNU
 packages can probably guess what the address is, but it would still be
 good to actually include the address in the README.

It's listed in the paragraph just below that one.
But I've added another mention with the patch below:

From 82169bbf6efeb9d60fc457cfd995c3ff0497365b Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sat, 18 Apr 2009 09:17:04 +0200
Subject: [PATCH] doc: update README

* README: (Reporting bugs): List the bug-reporting address here, too,
not just in the following more test-oriented paragraph.
Reported by Tim Mooney.
All changes are no longer listed in version-controlled ChangeLog
files, so note that contributions are attributed in the commit logs.
Mention bootstrap.conf, now that it's the authoritative source of
minimal prerequisite program/version# pairs.
---
 README |   14 ++
 1 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/README b/README
index e7499e7..08e0bab 100644
--- a/README
+++ b/README
@@ -41,7 +41,7 @@ Special thanks to Paul Eggert, Brian Matthews, Bruce Evans, 
Karl Berry,
 Kaveh Ghazi, and François Pinard for help with debugging and porting
 these programs.  Many thanks to all of the people who have taken the
 time to submit problem reports and fixes.  All contributed changes are
-attributed in the ChangeLog files.
+attributed in the commit logs.

 And thanks to the following people who have provided accounts for
 portability testing on many different types of systems: Bob Proulx,
@@ -173,6 +173,10 @@ run this command:
 For some tests, you can get even more detail by adding DEBUG=yes.
 Then include the contents of the file `log' in your bug report.

+Send bug reports, questions, comments, etc. to bug-coreut...@gnu.org.
+If you would like to suggest a patch, see

make check problems with coreutils 7.2 and earlier

2009-04-17 Thread Tim Mooney 


[I'm not subscribed to bug-coretuils, please Cc: me on any relevant
replies]

All-

I'm building coreutils on x86_64-sun-solaris2.10, with the Sun Studio 12
and/or Express compilers.  I'm building in 64 bit mode.  Everything builds
just fine, but before I finish packaging the software I always run make
check, to see what problems might turn up and how make check from one
version of the software differs from make check in previous versions.

I haven't been able to successfully use make check with coreutils in
a while.  The problem appears to be that several of the tests are
performed without the correct PATH, because instead of getting the
version of the program that was compiled in src/, it's getting the version
of a particular command that's part of the OS.  This is especially
problematic when testing yes.  The Solaris version of yes doesn't
support any of the command line arguments that the tests try, so the
tests essentially hang while Solaris' yes loops continuously outputting
things like --help.

I'm configuring the software like this

./configure --prefix=/local/gnu --exec-prefix=/local/gnu \
--build x86_64-sun-solaris2.10 \
--sysconfdir=/etc/local/gnu --libdir=/local/gnu/lib/64 \
--mandir=/local/gnu/share/man --infodir=/local/gnu/share/info \
--localstatedir=/var/local/gnu \
--disable-nls

and then doing

gmake
gmake check VERBOSE=yes

(gmake is GNU make 3.81).

I've checked the mailing list archives and I don't see any recent reports
of this issue, though, and I would think others would have run into the
same thing.  Is this a known issue, or should I investigate further?

Also, the README that comes with coreutils has a section on Reporting
bugs and what you should do when reporting them, but it doesn't actually
include the address to report them to.  People familiar with other GNU
packages can probably guess what the address is, but it would still be
good to actually include the address in the README.

Thanks,

Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing  Infrastructure  701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164


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