Re: coreutils-6.11 released
On 25.04.2008 21:04, Jim Meyering wrote: Christophe LYON [EMAIL PROTECTED] wrote: If I manually add -lm, I get: .../bin/../lib/gcc/sparc-sun-solaris2.8/4.1.0/crt1.o:(.plt+0x0): multiple definition of `_PROCEDURE_LINKAGE_TABLE_' /usr/lib/libm.so:(.plt+0x0): first defined here Is this a supported host? [...] If using your -lm library causes link errors like you show above, that could well explain why POW_LIB is not being set properly. This is exactly the error that 'configure' received when trying to use -lm. I solved the issue by moving to gcc-4.2.0 + binutils-2.18. Christophe. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.11 released
Christophe LYON [EMAIL PROTECTED] wrote: On 25.04.2008 21:04, Jim Meyering wrote: Christophe LYON [EMAIL PROTECTED] wrote: If I manually add -lm, I get: .../bin/../lib/gcc/sparc-sun-solaris2.8/4.1.0/crt1.o:(.plt+0x0): multiple definition of `_PROCEDURE_LINKAGE_TABLE_' /usr/lib/libm.so:(.plt+0x0): first defined here Is this a supported host? [...] If using your -lm library causes link errors like you show above, that could well explain why POW_LIB is not being set properly. This is exactly the error that 'configure' received when trying to use -lm. I solved the issue by moving to gcc-4.2.0 + binutils-2.18. It's good to know that fixed it. Thanks for letting us know. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Elbert Pol] Re: coreutils-6.11 released
Hi Jim, Curious if the log give you some usefull info? Jim Meyering wrote: Elbert Pol[EMAIL PROTECTED] wrote: ... Remember when you chose not to run make -k check? ;-) Well, now would be a good time to go back and do that, but with working tools in your PATH, of course. Hoi Jim, As you told before this fails :( I attach check.log Try again, but this time be sure to use -k, as suggested above. Then it won't stop at the first failure. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Elbert Pol] Re: coreutils-6.11 released
Elbert Pol [EMAIL PROTECTED] wrote: Jim Meyering wrote: Elbert Pol[EMAIL PROTECTED] wrote: Hoi Jim, When i use the new rm.exe and use it with the ./configure i get all kind of errors like : rm.exe: cannot remove `conftest': Is a directory rm.exe: cannot remove `conftest.dir': Is a directory rm.exe: FATAL: cannot enter directory `conftest': Bad file number rm.exe: FATAL: cannot enter directory `conftest.dir': Bad file number I don't have it when i use the rm.exe from 5.94 I attach the log file. Mayby you know what wrong ? Not yet. Remember when you chose not to run make -k check? ;-) Well, now would be a good time to go back and do that, but with working tools in your PATH, of course. Hoi again, Hope i attach now the good one :) Lots of unusual errors. No diff program? I think diff must be missing or non-functional. Otherwise, we'd have better output telling us about particular test failures. The number and distribution of failures make me pretty sure that the tests are failing due to a mismatch between the tests' expecting newlines in output and your executables generating CRs. For example, run these cd tests/cut ../../src/cut.exe -d: -f1,3- 1.I | diff -u - 1.O [or if you lack diff, do this: ] cd tests/cut ../../src/cut.exe -d: -f1,3- 1.I | cmp - 1.O ../../src/cut.exe -d: -f1,3- 1.I | cat -A ../../src/cut.exe -d: -f1,3- 1.I | od -ac That last one gives me this: $ ../../src/cut -d: -f1,3- 1.I | od -ac 000 a : c nl a : c \n 004 Also, the test output suggests that there is a broken rm command in your path. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Elbert Pol] Re: coreutils-6.11 released
Hoi Jim, When i use the new rm.exe and use it with the ./configure i get all kind of errors like : rm.exe: cannot remove `conftest': Is a directory rm.exe: cannot remove `conftest.dir': Is a directory rm.exe: FATAL: cannot enter directory `conftest': Bad file number rm.exe: FATAL: cannot enter directory `conftest.dir': Bad file number I don't have it when i use the rm.exe from 5.94 I attach the log file. Mayby you know what wrong ? Jim Meyering wrote: Forwarding manually. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils config.out.bz2 Description: Binary data ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Elbert Pol] Re: coreutils-6.11 released
Elbert Pol [EMAIL PROTECTED] wrote: Hoi Jim, When i use the new rm.exe and use it with the ./configure i get all kind of errors like : rm.exe: cannot remove `conftest': Is a directory rm.exe: cannot remove `conftest.dir': Is a directory rm.exe: FATAL: cannot enter directory `conftest': Bad file number rm.exe: FATAL: cannot enter directory `conftest.dir': Bad file number I don't have it when i use the rm.exe from 5.94 I attach the log file. Mayby you know what wrong ? Not yet. Remember when you chose not to run make -k check? ;-) Well, now would be a good time to go back and do that, but with working tools in your PATH, of course. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Elbert Pol] Re: coreutils-6.11 released
Jim Meyering wrote: Elbert Pol[EMAIL PROTECTED] wrote: Hoi Jim, When i use the new rm.exe and use it with the ./configure i get all kind of errors like : rm.exe: cannot remove `conftest': Is a directory rm.exe: cannot remove `conftest.dir': Is a directory rm.exe: FATAL: cannot enter directory `conftest': Bad file number rm.exe: FATAL: cannot enter directory `conftest.dir': Bad file number I don't have it when i use the rm.exe from 5.94 I attach the log file. Mayby you know what wrong ? Not yet. Remember when you chose not to run make -k check? ;-) Well, now would be a good time to go back and do that, but with working tools in your PATH, of course. Hoi Jim, As you told before this fails :( I attach check.log check.out.bz2 Description: Binary data cut-tests.log.bz2 Description: Binary data test-suite.log.bz2 Description: Binary data ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Elbert Pol] Re: coreutils-6.11 released
Elbert Pol [EMAIL PROTECTED] wrote: ... Remember when you chose not to run make -k check? ;-) Well, now would be a good time to go back and do that, but with working tools in your PATH, of course. Hoi Jim, As you told before this fails :( I attach check.log Try again, but this time be sure to use -k, as suggested above. Then it won't stop at the first failure. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Elbert Pol] Re: coreutils-6.11 released
Jim Meyering wrote: Elbert Pol[EMAIL PROTECTED] wrote: Hoi Jim, When i use the new rm.exe and use it with the ./configure i get all kind of errors like : rm.exe: cannot remove `conftest': Is a directory rm.exe: cannot remove `conftest.dir': Is a directory rm.exe: FATAL: cannot enter directory `conftest': Bad file number rm.exe: FATAL: cannot enter directory `conftest.dir': Bad file number I don't have it when i use the rm.exe from 5.94 I attach the log file. Mayby you know what wrong ? Not yet. Remember when you chose not to run make -k check? ;-) Well, now would be a good time to go back and do that, but with working tools in your PATH, of course. Hoi Jim, I notice now i forgot the -k option, i send later a log with -k added :) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Elbert Pol] Re: coreutils-6.11 released
Jim Meyering wrote: Elbert Pol[EMAIL PROTECTED] wrote: Hoi Jim, When i use the new rm.exe and use it with the ./configure i get all kind of errors like : rm.exe: cannot remove `conftest': Is a directory rm.exe: cannot remove `conftest.dir': Is a directory rm.exe: FATAL: cannot enter directory `conftest': Bad file number rm.exe: FATAL: cannot enter directory `conftest.dir': Bad file number I don't have it when i use the rm.exe from 5.94 I attach the log file. Mayby you know what wrong ? Not yet. Remember when you chose not to run make -k check? ;-) Well, now would be a good time to go back and do that, but with working tools in your PATH, of course. Hoi again, Hope i attach now the good one :) check.out1.bz2 Description: Binary data ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.11 released
Christophe LYON [EMAIL PROTECTED] wrote: On 19.04.2008 23:21, Jim Meyering wrote: Coreutils version 6.11 has been released. This is a stable release. Hello, My build fails on a Solaris 8 machine, using gcc-4.1.0. When building sort, I get: .../gcc -std=gnu99 -O2 -Wl,--as-needed -o sort sort.o ../lib/libcoreutils.a ../lib/libcoreutils.a -lsocket ../lib/libcoreutils.a(strtod.o): In function `rpl_strtod': strtod.c:(.text+0x18c): undefined reference to `pow' strtod.c:(.text+0x634): undefined reference to `pow' strtod.c:(.text+0x6a4): undefined reference to `pow' collect2: ld returned 1 exit status If I manually add -lm, I get: .../bin/../lib/gcc/sparc-sun-solaris2.8/4.1.0/crt1.o:(.plt+0x0): multiple definition of `_PROCEDURE_LINKAGE_TABLE_' /usr/lib/libm.so:(.plt+0x0): first defined here Is this a supported host? Thanks for the report. As far as I know, coreutils-6.11 does build on that system. Maybe your compiler or linker is not working properly? If that's the case, you will probably see clues in config.log. Normally, the build procedure detects the need for -lm and arranges to use it to sort's link command via the $(POW_LIB) variable mentioned in Makefile.am. If using your -lm library causes link errors like you show above, that could well explain why POW_LIB is not being set properly. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[Elbert Pol] Re: coreutils-6.11 released
Forwarding manually. ---BeginMessage--- Hmmm hoi Jim, Thats indeed strange. I attach both files Jim Meyering wrote: Elbert Pol[EMAIL PROTECTED] wrote: I try that build, but is fails now at a earlyer point. Well, your logs show that configure succeeded, which means the failure is _later_. And that means my patch solved the problem. I attach logs Thank you. The first interesting part is here: In file included from file-set.h:2, from file-set.c:20: sys/stat.h:267:8: operator '!' has no right operand make.exe[3]: *** [file-set.o] Error 1 That suggests that HAVE_LSTAT is not expanded as expected in lib/sys/stat.h. The template, lib/sys_stat.in.h has this: #if ! @HAVE_LSTAT@ # define lstat stat #endif yet, the diagnostic above suggests your lib/sys/stat.h looks like this: #if ! # define lstat stat #endif Contrast that with your config.log file, which says #define HAVE_LSTAT 1 So, would you please post both your lib/sys/stat.h, to confirm, and config.status, since it is the file responsible for performing the substitution that may be failing. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils config.status.bz2 Description: Binary data stat.h.bz2 Description: Binary data ---End Message--- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.11 released
Elbert Pol [EMAIL PROTECTED] wrote: Jim Meyering wrote: Elbert Pol[EMAIL PROTECTED] wrote: I try that build, but is fails now at a earlyer point. Well, your logs show that configure succeeded, which means the failure is _later_. And that means my patch solved the problem. I attach logs Thank you. The first interesting part is here: In file included from file-set.h:2, from file-set.c:20: sys/stat.h:267:8: operator '!' has no right operand make.exe[3]: *** [file-set.o] Error 1 That suggests that HAVE_LSTAT is not expanded as expected in lib/sys/stat.h. The template, lib/sys_stat.in.h has this: #if ! @HAVE_LSTAT@ # define lstat stat #endif yet, the diagnostic above suggests your lib/sys/stat.h looks like this: #if ! # define lstat stat #endif Contrast that with your config.log file, which says #define HAVE_LSTAT 1 So, would you please post both your lib/sys/stat.h, to confirm, and config.status, since it is the file responsible for performing the substitution that may be failing. [ Etiquette problems: you dropped the bug-coreutils Cc: on your reply. Please stop doing that. It makes more work for us. It's easier to follow discussions like this is you do not top post. I.e., include newer comments at the bottom, not at the top. I've just moved your comments to the bottom. ] Hmmm hoi Jim, Thats indeed strange. I attach both files Thank you. They show that your stat.h file comes from coreutils-6.11, not from the snapshot. The build problem is actually coming from the mkdir-related block just after the one I mentioned above, and that particular problem appears to be fixed in the snapshot, thanks to Bruno's gnulib patch to work around a mingw build failure. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Elbert Pol] Re: coreutils-6.11 released
Jim Meyering wrote: Forwarding manually. Hello Jim, Sorry for the mail trouble. I have use the test version and also send the Stat.h from the test version. --- U:\Core\lib\sys\stat.h 2008-04-22 20:40:18.0 + +++ U:\coreutils-6.11\lib\sys\stat.h2008-04-20 10:20:02.0 + @@ -268,7 +268,7 @@ /* mingw's _mkdir() function has 1 argument, but we pass 2 arguments. Additionally, it declares _mkdir (and depending on compile flags, an alias mkdir), only in the nonstandard io.h. */ -#if ! +#if ! 1 0 # include io.h static inline int ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Elbert Pol] Re: coreutils-6.11 released
Elbert Pol [EMAIL PROTECTED] wrote: I have use the test version and also send the Stat.h from the test version. --- U:\Core\lib\sys\stat.h2008-04-22 20:40:18.0 + +++ U:\coreutils-6.11\lib\sys\stat.h 2008-04-20 10:20:02.0 + Ahh... so you did. Sorry about that. This just-created snapshot should help: coreutils snapshot: http://meyering.net/cu/coreutils-ss.tar.gz8.7 MB http://meyering.net/cu/coreutils-ss.tar.lzma 3.7 MB aka http://meyering.net/cu/coreutils-6.11.17-d30ac.tar.lzma ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Elbert Pol] Re: coreutils-6.11 released
Elbert Pol [EMAIL PROTECTED] wrote: Jim Meyering wrote: Elbert Pol[EMAIL PROTECTED] wrote: I have use the test version and also send the Stat.h from the test version. --- U:\Core\lib\sys\stat.h 2008-04-22 20:40:18.0 + +++ U:\coreutils-6.11\lib\sys\stat.h2008-04-20 10:20:02.0 + Ahh... so you did. Sorry about that. This just-created snapshot should help: coreutils snapshot: http://meyering.net/cu/coreutils-ss.tar.gz8.7 MB http://meyering.net/cu/coreutils-ss.tar.lzma 3.7 MB aka http://meyering.net/cu/coreutils-6.11.17-d30ac.tar.lzma Hoi Jim, Yippi, The make Is working!! Good to hear ;-) Din't try to do make install yet. Just wanted to know if i have to do a make test first or ? You choose. Running make test is generally a good installation prerequisite, but tests sometimes fail due to portability problems in the tests themselves, rather than in the tools, so... ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Elbert Pol] Re: coreutils-6.11 released
Jim Meyering wrote: Elbert Pol[EMAIL PROTECTED] wrote: Jim Meyering wrote: Elbert Pol[EMAIL PROTECTED] wrote: I have use the test version and also send the Stat.h from the test version. --- U:\Core\lib\sys\stat.h 2008-04-22 20:40:18.0 + +++ U:\coreutils-6.11\lib\sys\stat.h2008-04-20 10:20:02.0 + Ahh... so you did. Sorry about that. This just-created snapshot should help: coreutils snapshot: http://meyering.net/cu/coreutils-ss.tar.gz8.7 MB http://meyering.net/cu/coreutils-ss.tar.lzma 3.7 MB aka http://meyering.net/cu/coreutils-6.11.17-d30ac.tar.lzma Hoi Jim, Yippi, The make Is working!! Good to hear ;-) Din't try to do make install yet. Just wanted to know if i have to do a make test first or ? You choose. Running make test is generally a good installation prerequisite, but tests sometimes fail due to portability problems in the tests themselves, rather than in the tools, so... Hoi Jim, I rather choose for make install :P And the make install finish without a error. I let some other peeps test it, and let you know about the results. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.11 released
Elbert Pol [EMAIL PROTECTED] wrote: ... Hope it's fixable :) Anything is fixable ;-) Jim Meyering wrote: Elbert Pol[EMAIL PROTECTED] wrote: ... make.exe[2]: Entering directory `U:/coreutils-6.11/man' make.exe[2]: *** No rule to make target `uname.1 ', needed by `all-am'. Stop. Hi Elbert, Thanks for the details. I should have seen it the first time: The mention of uname.1 includes something fishy that makes the trailing ' appear on the next line. More carriage return problems. Here's a snapshot with the fix: http://meyering.net/cu/coreutils-6.11.11-0bc881.tar.lzma Here's the patch I expect to push, once you confirm it solves that problem: From 0bc8813b1e40435ced17c555149e26c5aadbdda6 Mon Sep 17 00:00:00 2001 From: Jim Meyering [EMAIL PROTECTED] Date: Tue, 22 Apr 2008 10:52:37 +0200 Subject: [PATCH] Accommodate building on OS/2 (www.ecomstation.com Ecs v2 rc4) * configure.ac: Filter out carriage returns in more places. Reported by Elbert Pol, details here: http://thread.gmane.org/gmane.org.fsf.announce/867/focus=13332 Signed-off-by: Jim Meyering [EMAIL PROTECTED] --- configure.ac |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index 4cd0d7c..adf2903 100644 --- a/configure.ac +++ b/configure.ac @@ -259,7 +259,7 @@ mk=$srcdir/src/Makefile.am v=EXTRA_PROGRAMS for gl_i in `sed -n '/^'$v' =/,/[[^\]]$/p' $mk \ | sed 's/^ *//;/^\$.*/d;/^'$v' =/d' \ -| tr -s '\\012' ' '`; do +| tr -s '\\015\\012' ' '`; do gl_ADD_PROG([optional_bin_progs], $gl_i) done @@ -310,10 +310,11 @@ case $optional_bin_progs in *)INSTALL_SU=no ;; esac -MAN=`echo $optional_bin_progs |sed 's/ /.1 /g;s/ $//'` +MAN=`echo $optional_bin_progs |sed 's/ /.1 /g;s/ $//'|tr -d '\\015\\012'` # Change ginstall.1 to install.h in $MAN. -MAN=`for m in $MAN; do test $m = ginstall.1 m=install.1; echo $m; done | tr '\012' ' '; echo` +MAN=`for m in $MAN; do test $m = ginstall.1 m=install.1; echo $m; done \ + | tr '\015\012' ' '; echo` # Remove [.1, since writing a portable rule for it in man/Makefile.am # is not practical. The sed LHS below uses the autoconf quadrigraph -- 1.5.5.76.gae22a ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.11 released
On 19.04.2008 23:21, Jim Meyering wrote: Coreutils version 6.11 has been released. This is a stable release. Hello, My build fails on a Solaris 8 machine, using gcc-4.1.0. When building sort, I get: .../gcc -std=gnu99 -O2 -Wl,--as-needed -o sort sort.o ../lib/libcoreutils.a ../lib/libcoreutils.a -lsocket ../lib/libcoreutils.a(strtod.o): In function `rpl_strtod': strtod.c:(.text+0x18c): undefined reference to `pow' strtod.c:(.text+0x634): undefined reference to `pow' strtod.c:(.text+0x6a4): undefined reference to `pow' collect2: ld returned 1 exit status If I manually add -lm, I get: .../bin/../lib/gcc/sparc-sun-solaris2.8/4.1.0/crt1.o:(.plt+0x0): multiple definition of `_PROCEDURE_LINKAGE_TABLE_' /usr/lib/libm.so:(.plt+0x0): first defined here Is this a supported host? Regards, Christophe. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.11 released
Elbert Pol [EMAIL PROTECTED] wrote: I try that build, but is fails now at a earlyer point. Well, your logs show that configure succeeded, which means the failure is _later_. And that means my patch solved the problem. I attach logs Thank you. The first interesting part is here: In file included from file-set.h:2, from file-set.c:20: sys/stat.h:267:8: operator '!' has no right operand make.exe[3]: *** [file-set.o] Error 1 That suggests that HAVE_LSTAT is not expanded as expected in lib/sys/stat.h. The template, lib/sys_stat.in.h has this: #if ! @HAVE_LSTAT@ # define lstat stat #endif yet, the diagnostic above suggests your lib/sys/stat.h looks like this: #if ! # define lstat stat #endif Contrast that with your config.log file, which says #define HAVE_LSTAT 1 So, would you please post both your lib/sys/stat.h, to confirm, and config.status, since it is the file responsible for performing the substitution that may be failing. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.11 released
Elbert Pol [EMAIL PROTECTED] wrote: Hoi Jim, and the rest I try to debug some things for os2 and it seems a hell of a job :( Espicely if you have no backgrounds about the debugger. But i saw newer Coreutils 6.11 i thought i try and the configuratie went smootly this time :P Then i did make and now it stops at gcc -std=gnu99 -D__EMX__ -DOS2 -D__ST_MT_ERRNO__ -O3 -mcpu=pentium3 -Zexe -Zomf -Zmap -Zargs-wild -Zbin-files -D__ST_MT_ERRNO__ -s -o su.exe su.o ../lib/libcoreutils.a ../lib/libcoreutils.a make.exe[3]: Leaving directory `U:/coreutils-6.11/src' make.exe[2]: Leaving directory `U:/coreutils-6.11/src' Making all in doc make.exe[2]: Entering directory `U:/coreutils-6.11/doc' make.exe[2]: Nothing to be done for `all'. make.exe[2]: Leaving directory `U:/coreutils-6.11/doc' Making all in man make.exe[2]: Entering directory `U:/coreutils-6.11/man' make.exe[2]: *** No rule to make target `uname.1 ', needed by `all-am'. Stop. make.exe[2]: Leaving directory `U:/coreutils-6.11/man' make.exe[1]: *** [all-recursive] Error 1 make.exe[1]: Leaving directory `U:/coreutils-6.11' make: *** [all] Error 2 Hi Elbert, Thanks for the report. Please show precisely what you have done, starting with the distribution tarball. E.g, if you ran these commands, say that, and send the log file: gzip -dc coreutils-6.11.tar.gz|tar xf - ./configure log 21 make log 21 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [OpenAFS] Re: coreutils-6.11 released
If by unknown you mean nameless, that's not what the patch does. Such a patch would not even have been considered. I agree that hiding this information in some cases might not be optimal, but the main problem is that through this the 'groups' command becomes utterly useless and confused quite a lot of users. $ groups users id: cannot find name for group ID 1091323188 1091323188 further $ id -Gn users id: cannot find name for group ID 1091323188 1091323188 Because of this I get many scripts that scan /etc/group and /etc/passwd in a loop and when I ask why they don't use 'grous' or 'id' I get Ahh this has been broken for a long time or Somehow my computer is broken. Is there a way of maybe instead of giving an error message to give back a pag name. My intent was not to hide the number it was to hide the error because people think their systems are broken even if there are not. I can see the conflict here between users and sysadmins. Does someone know if there is a way to find out if the group is a pag group or not. Then I could write a version that still shows the group number but suppresses the error. Would that be OK? Cheers Didi --- www.cern.ch/ribalba / www.ribalba.de Email / Jabber: [EMAIL PROTECTED] Phone (Work) : +41 22 7679376 Skype : ribalba Address : CERN / IT-FIO-FS / GENEVE 23/ SCHWEIZ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.11 released
Hoi Jim, I used the lzma and after that i untar the tar file I attach the log Hope it's fixable :) Jim Meyering wrote: Elbert Pol[EMAIL PROTECTED] wrote: Hoi Jim, and the rest I try to debug some things for os2 and it seems a hell of a job :( Espicely if you have no backgrounds about the debugger. But i saw newer Coreutils 6.11 i thought i try and the configuratie went smootly this time :P Then i did make and now it stops at gcc -std=gnu99 -D__EMX__ -DOS2 -D__ST_MT_ERRNO__ -O3 -mcpu=pentium3 -Zexe -Zomf -Zmap -Zargs-wild -Zbin-files -D__ST_MT_ERRNO__ -s -o su.exe su.o ../lib/libcoreutils.a ../lib/libcoreutils.a make.exe[3]: Leaving directory `U:/coreutils-6.11/src' make.exe[2]: Leaving directory `U:/coreutils-6.11/src' Making all in doc make.exe[2]: Entering directory `U:/coreutils-6.11/doc' make.exe[2]: Nothing to be done for `all'. make.exe[2]: Leaving directory `U:/coreutils-6.11/doc' Making all in man make.exe[2]: Entering directory `U:/coreutils-6.11/man' make.exe[2]: *** No rule to make target `uname.1 ', needed by `all-am'. Stop. make.exe[2]: Leaving directory `U:/coreutils-6.11/man' make.exe[1]: *** [all-recursive] Error 1 make.exe[1]: Leaving directory `U:/coreutils-6.11' make: *** [all] Error 2 Hi Elbert, Thanks for the report. Please show precisely what you have done, starting with the distribution tarball. E.g, if you ran these commands, say that, and send the log file: gzip -dc coreutils-6.11.tar.gz|tar xf - ./configure log 21 make log 21 log.bz2 Description: Binary data ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [OpenAFS] Re: coreutils-6.11 released
Didi [EMAIL PROTECTED] wrote: If by unknown you mean nameless, that's not what the patch does. Such a patch would not even have been considered. I agree that hiding this information in some cases might not be optimal, but the main problem is that through this the 'groups' command becomes utterly useless and confused quite a lot of users. $ groups users id: cannot find name for group ID 1091323188 1091323188 further $ id -Gn users id: cannot find name for group ID 1091323188 1091323188 If someone can provide code to determine efficiently whether a nameless GID is a PAG then we can probably make everyone happy. If that happens, I'll need to know if there's a standard or accepted mapping from GID to PAG group name. Pointers to unencumbered code would be welcome. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [OpenAFS] Re: coreutils-6.11 released
On Apr 21, 2008, at 4:23 , Didi wrote: If by unknown you mean nameless, that's not what the patch does. Such a patch would not even have been considered. I agree that hiding this information in some cases might not be optimal, but the main problem is that through this the 'groups' command becomes utterly useless and confused quite a lot of users. $ groups users id: cannot find name for group ID 1091323188 1091323188 I touched on a solution to that in the part of my message that you elided. I admit I was rather confused by what exactly was being cited as the problem, but this is on I do know about. (I'd actually love to see some kind of plugin setup so an AFS PAG shower could be added, but at the same time that seems just a little bit silly/ overblown for simple stuff like id and groups.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.11 released
Russ Allbery [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: Coreutils version 6.11 has been released. This is a stable release. ** Improvements id and groups work around an AFS-related bug whereby those programs would print an invalid group number, when given no user-name argument. I'm hoping that this doesn't mean that coreutils suppresses display of the PAG group on a system running AFS, since seeing that group is valuable for debugging. It really is a supplemental group of the process, even though it's created in the kernel rather than initialized from /etc/groups. For example: windlord:~ id uid=1000(eagle) gid=0(root) groups=0(root),4(adm),24(cdrom),29(audio),44(video),1000(eagle),1103312837 windlord:~ id --version id (GNU coreutils) 6.10 that final group number is useful information. It was always one of the features of GNU id over, for example, the Solaris implementation that it didn't suppress that group number, and I've used that before in programs. Copied to the AFS list so that people are aware that a change happened in this area, in case anyone notices differences after a coreutils upgrade. You can tell I don't use AFS and didn't do my homework. I wish you'd noticed and spoken up a month or so ago. Knowing that, I expect to revert that patch -- unless someone can come up with a very good argument for the new behavior. Out of curiosity, how have you used it? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.11 released
Jim Meyering wrote:
Coreutils version 6.11 has been released. This is a stable release.
Since 6.10, there have been 200 change sets in coreutils proper and almost
300 in gnulib (most of the files in coreutils/{lib,m4} come from gnulib).
*
NEWS (since coreutils-6.10)
*
* Noteworthy changes in release 6.11 (2008-04-19) [stable]
** New features
join now verifies that the inputs are in sorted order. This check can
be turned off with the --nocheck-order option.
sort accepts the new option --sort=WORD, where WORD can be one of
general-numeric, month, numeric or random. These are equivalent to the
options --general-numeric-sort/-g, --month-sort/-M, --numeric-sort/-n
and --random-sort/-R, resp.
--sort=version ??? What happened?
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.11 released
Bruce Korb wrote: --sort=version ??? What happened? We are waiting for you to send in your copyright assignment paperwork before that patch can be included. Or if you did send it in then we are waiting for the GNU copyright clerk to process it. I sent you the forms in early February 2008. Those need to be signed and sent to the copyright clerk. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
--sort=version patches (Re: coreutils-6.11 released)
Bob Proulx wrote: Bruce Korb wrote: --sort=version ??? What happened? We are waiting for you to send in your copyright assignment paperwork before that patch can be included. Or if you did send it in then we are waiting for the GNU copyright clerk to process it. I sent you the forms in early February 2008. Those need to be signed and sent to the copyright clerk. Looking at my email I see that you requested the paper documents from the copyright clerk on 9 Feb 2008. The paper form should have arrived in your post office mailbox somewhere around the 14th. If they did not then please request them from the copyright clerk again. Those need to be signed and sent back to the copyright clerk. If you did already send those off then we should ask the copyright clerk to follow up on them. There may have been delays in the office. And then we get to work on adding tests. But I said I would help with that part of things. I would like to see this feature added too. :-) Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-6.11 released
Jim Meyering [EMAIL PROTECTED] writes: You can tell I don't use AFS and didn't do my homework. I wish you'd noticed and spoken up a month or so ago. Unfortunately, I only follow the announcement list. :/ Knowing that, I expect to revert that patch -- unless someone can come up with a very good argument for the new behavior. Out of curiosity, how have you used it? Usually to tell whether two shells are in different PAGs, which is useful when hunting down problems with AFS PAM modules and the like. Also to tell whether a process is in a PAG at all, although with current Linux kernels the keyring is the canonical place where that's stored. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [OpenAFS] Re: coreutils-6.11 released
On Sun, 20 Apr 2008 11:37:44 -0700 Russ Allbery [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: You can tell I don't use AFS and didn't do my homework. I wish you'd noticed and spoken up a month or so ago. Unfortunately, I only follow the announcement list. :/ Knowing that, I expect to revert that patch -- unless someone can come up with a very good argument for the new behavior. Out of curiosity, how have you used it? Usually to tell whether two shells are in different PAGs, which is useful when hunting down problems with AFS PAM modules and the like. Also to tell whether a process is in a PAG at all, although with current Linux kernels the keyring is the canonical place where that's stored. Sure. There are PAG prettifiers like libnss-afs that make it look a bit different, like 1103204785(AfsPag-c191b1) but still that's just a variation of the basic theme and having it show up in any form is indispensable. Regards, -doc ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [OpenAFS] Re: coreutils-6.11 released
On Apr 20, 2008, at 14:37 , Russ Allbery wrote: Jim Meyering [EMAIL PROTECTED] writes: Knowing that, I expect to revert that patch -- unless someone can come up with a very good argument for the new behavior. Out of curiosity, how have you used it? Usually to tell whether two shells are in different PAGs, which is useful when hunting down problems with AFS PAM modules and the like. Also to tell whether a process is in a PAG at all, although with current Linux kernels the keyring is the canonical place where that's stored. Putting on my sysadmin hat, I am somewhat baffled by this discussion. Completely hiding unknown groups? I would print numerically and return a nonzero exit status (the latter possibly overrideable for OpenAFS use where they are expected); hiding them completely isn't just a way to annoy OpenAFS users, it also hides a clue to a system configuration problem (namely, missing groups in the group database). If someone actually needs the hiding behavior, make it an option (possibly invokable via an environment variable). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Coreutils-announce] coreutils-6.11 released
[EMAIL PROTECTED] (Karl Berry) wrote: join now verifies that the inputs are in sorted order. This check can How about doing the same for comm? Makes sense. Did you just volunteer? ;-) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Coreutils-announce] coreutils-6.11 released
On Sun, Apr 20, 2008 at 5:24 PM, Jim Meyering [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Karl Berry) wrote: join now verifies that the inputs are in sorted order. This check can How about doing the same for comm? Makes sense. Did you just volunteer? ;-) If not, I'll be happy to do it. Bo ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Coreutils-announce] coreutils-6.11 released
If not, I'll be happy to do it. Please! Thanks, k ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
coreutils-6.11 released
Coreutils version 6.11 has been released. This is a stable release.
Since 6.10, there have been 200 change sets in coreutils proper and almost
300 in gnulib (most of the files in coreutils/{lib,m4} come from gnulib).
Thanks to everyone who has contributed to this release.
This time, a trio from Stanford, Cristian Cadar, Daniel Dunbar and
Dawson Engler deserve special thanks for discovering an amazing number
of bugs (usually segfault-inducing), one in each of the following tools:
pr, md5sum (also affecting sha*sum), mknod, mkfifo, mkdir, paste and ptx.
For a summary of changes and contributors, see:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=shortlog;h=v6.11
or run this command from a git-cloned coreutils directory:
git shortlog v6.10..v6.11
To summarize the gnulib-related changes, you can run this command
From a git-cloned gnulib directory:
git shortlog 16c6ed60fb53998428f510f649ee6b57fea30f35\
..2e8956774250d3f5636898fea193c5abaf041d08
Here are the compressed sources:
ftp://ftp.gnu.org/gnu/coreutils/coreutils-6.11.tar.gz (8.8MB)
ftp://ftp.gnu.org/gnu/coreutils/coreutils-6.11.tar.lzma (3.6MB)
Here are the GPG detached signatures[*]:
ftp://ftp.gnu.org/gnu/coreutils/coreutils-6.11.tar.gz.sig
ftp://ftp.gnu.org/gnu/coreutils/coreutils-6.11.tar.lzma.sig
For more information on LZMA compression, see http://tukaani.org/lzma/.
Since the lzma-compressed tarball is 2MB smaller than the .bz2 one,
and since it decompresses twice as fast, I no longer create bzip2-
compressed tarballs.
[*] You can use either of the above signature files to verify that
the corresponding file (without the .sig suffix) is intact. First,
be sure to download both the .sig file and the corresponding tarball.
Then, run a command like this:
gpg --verify coreutils-6.11.tar.gz.sig
If that command fails because you don't have the required public key,
then run this command to import it:
gpg --keyserver wwwkeys.pgp.net --recv-keys B9AB9A16
and rerun the `gpg --verify' command.
This release was bootstrapped with the following tools:
Autoconf 2.62
Automake 1.10a
Bison 2.3a
Gnulib v0.0-513-g2e89567
*
How can you help?
*
If you're interested in lending a hand, or just want to use
the latest versions right now, you can build these programs
and run the test suite like this:
gzip -dc coreutils-6.11.tar.gz | tar xf -
cd coreutils-6.11
./configure
make
make -k check log
grep FAIL log
[If you downloaded the much-smaller .lzma tarball, then just
substitute this for the gzip... line above:
lzma -dc coreutils-6.11.tar.lzma | tar xf -
If you don't have lzma installed yet, first try getting it via
your distribution, e.g., aptitude install lzma or yum install lzma]
Be sure to use make's -k option so that make doesn't stop
just because one of the earlier tests fails.
Please report any build problems or test failures to the
bug-coreutils@gnu.org mailing list.
There are detailed instructions in the `Reporting bugs:' section
of the README file.
*
NEWS (since coreutils-6.10)
*
* Noteworthy changes in release 6.11 (2008-04-19) [stable]
** Bug fixes
configure --enable-no-install-program=groups now works.
cp -fR fifo E now succeeds with an existing E. Before this fix, using
-fR to copy a fifo or special file onto an existing file would fail
with EEXIST. Now, it once again unlinks the destination before trying
to create the destination file. [bug introduced in coreutils-5.90]
dd once again works with unnecessary options like if=/dev/stdin and
of=/dev/stdout. [bug introduced in fileutils-4.0h]
id now uses getgrouplist, when possible. This results in
much better performance when there are many users and/or groups.
ls no longer segfaults on files in /proc when linked with an older version
of libselinux. E.g., ls -l /proc/sys would dereference a NULL pointer.
md5sum would segfault for invalid BSD-style input, e.g.,
echo 'MD5 (' | md5sum -c - Now, md5sum ignores that line.
sha1sum, sha224sum, sha384sum, and sha512sum are affected, too.
[bug introduced in coreutils-5.1.0]
md5sum -c would accept a NUL-containing checksum string like abcd\0...
and would unnecessarily read and compute the checksum of the named file,
and then compare that checksum to the invalid one: guaranteed to fail.
Now, it recognizes that the line is not valid and skips it.
sha1sum, sha224sum, sha384sum, and sha512sum are affected, too.
[bug present in the original version, in coreutils-4.5.1, 1995]
mkdir -Z x dir no longer segfaults when diagnosing invalid context x
mkfifo and mknod would fail similarly. Now they're fixed.
mv would mistakenly unlink a destination file before calling rename,
when the destination had two or more hard links. It no longer does that.
[bug introduced in coreutils-5.3.0]
paste -d'\' file no longer overruns memory (heap since coreutils-5.1.2,
stack before then) [bug
