Opened 16 years ago
Closed 16 years ago
#2249 closed task (fixed)
CoreUtils i18n patch
Reported by: | DJ Lucas | Owned by: | DJ Lucas |
---|---|---|---|
Priority: | high | Milestone: | 6.4 |
Component: | Book | Version: | SVN |
Severity: | normal | Keywords: | |
Cc: |
Description
Needs to go back into the book. New upstream version applies correctly, one test of the cut program fails. Currently testing against Alexander's proposed testsuite:
http://linuxfromscratch.org/pipermail/lfs-dev/2006-January/055425.html
Change History (9)
comment:1 by , 16 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:3 by , 16 years ago
follow-ups: 8 9 comment:6 by , 16 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
I'm reopening this ticket as I've experienced problems with the Coreutils test suite since adding back the i18n patch. I've run through my build sequence twice with the same results:
Both times this happens:
First, the su-tools nobody ... test fails with this simple output: make check-recursive make[1]: Entering directory `/build/coreutils-6.12' Making check in lib make[2]: Entering directory `/build/coreutils-6.12/lib'
cd .. && /bin/sh ./config.status lib/Makefile depfiles
./config.status: line 453: config.log: Permission denied make[2]: * [Makefile] Error 1 make[2]: Leaving directory `/build/coreutils-6.12/lib' make[1]: * [check-recursive] Error 1 make[1]: Leaving directory `/build/coreutils-6.12' make: * [check] Error 2
After that I simply enter the same exact command (su-tools nobody -s /bin/bash -c "make RUN_EXPENSIVE_TESTS=yes check") and the tests run, but fails one test (misc/cut). Here's some of the log output:
empty-fl... empty-fl.r... empty-fl.p... missing-fl... cut: test missing-fl: stderr mismatch, comparing missing-fl.E (actual) and missing-fl.3 (expected) * missing-fl.E Wed Oct 22 09:17:13 2008 --- missing-fl.3 Wed Oct 22 09:17:13 2008 * * 1,2 ! cut: invalid byte, character or field list
Try `cut --help' for more information.
--- 1,2 ---- ! cut: invalid byte or field list
Try `cut --help' for more information.
and many more errors with the cut tests. And yes, I've ensured that the nobody user/group exists as the instructions say.
I'm stopping here for the day (going to go work on the helicopter). I'll check back later and see if anyone can reproduce this.
follow-up: 10 comment:8 by , 16 years ago
Replying to randy@linuxfromscratch.org:
First, the su-tools nobody ... test fails with this simple output: make check-recursive make[1]: Entering directory `/build/coreutils-6.12' Making check in lib make[2]: Entering directory `/build/coreutils-6.12/lib'
cd .. && /bin/sh ./config.status lib/Makefile depfiles
./config.status: line 453: config.log: Permission denied make[2]: * [Makefile] Error 1 make[2]: Leaving directory `/build/coreutils-6.12/lib' make[1]: * [check-recursive] Error 1 make[1]: Leaving directory `/build/coreutils-6.12' make: * [check] Error 2
IIRC someone reported this on either -dev or -book at some point. I *think* the solution (or proposed solution, at least) was to chown config.log along with some of the other files. Not sure why it only happens once for you, though.
(And I haven't built anything in a long time, so I can't confirm one way or the other whether this is working...)
but fails one test (misc/cut). Here's some of the log output:
empty-fl... empty-fl.r... empty-fl.p... missing-fl... cut: test missing-fl: stderr mismatch, comparing missing-fl.E (actual) and missing-fl.3 (expected) * missing-fl.E Wed Oct 22 09:17:13 2008 --- missing-fl.3 Wed Oct 22 09:17:13 2008 * * 1,2 ! cut: invalid byte, character or field list
Try `cut --help' for more information.
--- 1,2 ---- ! cut: invalid byte or field list
Try `cut --help' for more information.
It *looks* like somebody changed the error output from cut, but not the expected output from the test. If the error message got changed by the i18n patch, then I suspect the test data (missing-f1.3) should be changed as well.
I'm stopping here for the day (going to go work on the helicopter). I'll check back later and see if anyone can reproduce this.
As above, I can't repro, but this seems plausible to me. :-)
comment:9 by , 16 years ago
Or, looking at this slightly more closely:
Replying to randy@linuxfromscratch.org:
Making check in lib
make[2]: Entering directory `/build/coreutils-6.12/lib'
cd .. && /bin/sh ./config.status lib/Makefile depfiles
I wonder why it's running config.status again? Looks like something in the Makefile decided that the Makefile needed to be regenerated? I wonder what lib/Makefile depends on...
follow-up: 11 comment:10 by , 16 years ago
Replying to Bryan Kadzban:
Replying to randy@linuxfromscratch.org:
First, the su-tools nobody ... test fails with this simple output: make check-recursive make[1]: Entering directory `/build/coreutils-6.12' Making check in lib make[2]: Entering directory `/build/coreutils-6.12/lib'
cd .. && /bin/sh ./config.status lib/Makefile depfiles
./config.status: line 453: config.log: Permission denied make[2]: * [Makefile] Error 1 make[2]: Leaving directory `/build/coreutils-6.12/lib' make[1]: * [check-recursive] Error 1 make[1]: Leaving directory `/build/coreutils-6.12' make: * [check] Error 2
IIRC someone reported this on either -dev or -book at some point. I *think* the solution (or proposed solution, at least) was to chown config.log along with some of the other files. Not sure why it only happens once for you, though.
Oops. Sorry about that...that change should have been committed. It should be:
chown -Rv nobody config.log {gnulib-tests,lib,src}/.deps
(And I haven't built anything in a long time, so I can't confirm one way or the other whether this is working...)
but fails one test (misc/cut). Here's some of the log output:
empty-fl... empty-fl.r... empty-fl.p... missing-fl... cut: test missing-fl: stderr mismatch, comparing missing-fl.E (actual) and missing-fl.3 (expected) * missing-fl.E Wed Oct 22 09:17:13 2008 --- missing-fl.3 Wed Oct 22 09:17:13 2008 * * 1,2 ! cut: invalid byte, character or field list
Try `cut --help' for more information.
--- 1,2 ---- ! cut: invalid byte or field list
Try `cut --help' for more information.
It *looks* like somebody changed the error output from cut, but not the expected output from the test. If the error message got changed by the i18n patch, then I suspect the test data (missing-f1.3) should be changed as well.
Yeah. The test was known to fail, as mentioned in the original bug, however I failed to add a note to the book...but since you've already identified the problem, I'm working on the testsuite instead of adding that note. Will send a fix to RH.
-- DJ Lucas
comment:11 by , 16 years ago
Replying to dj@linuxfromscratch.org:
Replying to Bryan Kadzban:
It *looks* like somebody changed the error output from cut, but not the expected output from the test. If the error message got changed by the i18n patch, then I suspect the test data (missing-f1.3) should be changed as well.
Yeah. The test was known to fail, as mentioned in the original bug, however I failed to add a note to the book...but since you've already identified the problem, I'm working on the testsuite instead of adding that note. Will send a fix to RH.
Spot on Bryan. Thanks.
--- coreutils-6.12-orig/tests/misc/cut 2008-05-17 01:41:11.000000000 -0500 +++ coreutils-6.12/tests/misc/cut 2008-10-22 18:14:25.000000000 -0500 @@ -26,7 +26,7 @@ my $prog = 'cut'; my $try = "Try \`$prog --help' for more information.\n"; my $from_1 = "$prog: fields and positions are numbered from 1\n$try"; -my $inval = "$prog: invalid byte or field list\n$try"; +my $inval = "$prog: invalid byte, character or field list\n$try"; my $no_endpoint = "$prog: invalid range with no endpoint: -\n$try"; my @Tests = @@ -141,7 +141,7 @@ # None of the following invalid ranges provoked an error up to coreutils-6.9. ['inval1', qw(-f 2-0), {IN=>''}, {OUT=>''}, {EXIT=>1}, - {ERR=>"$prog: invalid decreasing range\n$try"}], + {ERR=>"$inval"}], ['inval2', qw(-f -), {IN=>''}, {OUT=>''}, {EXIT=>1}, {ERR=>$no_endpoint}], ['inval3', '-f', '4,-', {IN=>''}, {OUT=>''}, {EXIT=>1}, {ERR=>$no_endpoint}], ['inval4', '-f', '1-2,-', {IN=>''}, {OUT=>''}, {EXIT=>1}, {ERR=>$no_endpoint}],
comment:12 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Test results posted on lfs-dev. http://archive.linuxfromscratch.org/mail-archives/lfs-dev/2008-October/062045.html Patch will go back in, but now we have a problem with grep that I've not investigated.