Summary: | dev-lang/gforth: fails tests | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Javran Cheng <javran.c> |
Component: | Current packages | Assignee: | Sergei Trofimovich (RETIRED) <slyfox> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | javran.c, jstein |
Priority: | Normal | Keywords: | TESTFAILURE |
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log |
Description
Javran Cheng
2013-11-12 18:28:00 UTC
Created attachment 363144 [details]
build.log
This package has no maintainer so this bug may go unnoticed for a long time. Gentoo has a dedicated team[1] for assisting users in maintaining orphaned packages. If you are interested in maintaining this package, please contact proxy-maint@gentoo.org. [1]: http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml I did some hacking to make it work for gforth 0.7.2: https://github.com/Javran/gentoo-javran/tree/master/dev-lang/gforth Let's leave the bug open until it's fixed in portage. Tests are not executed in gforth-0.7.3 during build-time, however they still fail (In reply to Sergey Popov from comment #5) > Tests are not executed in gforth-0.7.3 during build-time, however they still > fail Hello Sergey Popov, thanks for the updated ebuild. about the failed checks: I've just build gforth on amd64 and only one test failed (the "gforth-fast-noll-reg"), but other succeeded: [...] ./engine/gforth-fast-noll-reg -p ".:/usr/lib64/gforth/site-forth:/usr/share/gforth/site-forth:/usr/lib64/gforth/0.7.3:/usr/share/gforth/0.7.3:." test/signals.fs -e bye ./engine/gforth-fast-noll-reg -p ".:/usr/lib64/gforth/site-forth:/usr/share/gforth/site-forth:/usr/lib64/gforth/0.7.3:/usr/share/gforth/0.7.3:." test/coremore.fs test/gforth.fs -e bye 2>&1 | tr -d '\015' | diff -c - ./test/gforth.out *** - Fri Sep 12 16:32:23 2014 --- ./test/gforth.out Fri Oct 11 21:31:28 2013 *************** *** 1,7 **** ! redefined { INCORRECT RESULT: { 12.3456789e 7 3 1 f>str-rdp s" 12.346" str= -> true } ! INCORRECT RESULT: { 12.3456789e 7 4 1 f>str-rdp s" 12.3457" str= -> true } ! INCORRECT RESULT: { -12.3456789e 7 4 1 f>str-rdp s" -1.23E1" str= -> true } ! INCORRECT RESULT: { 0.0996e 7 3 1 f>str-rdp s" 0.100" str= -> true } ! INCORRECT RESULT: { 0.0996e 7 3 3 f>str-rdp s" 9.96E-2" str= -> true } ! INCORRECT RESULT: { 999.9994e 7 3 1 f>str-rdp s" 999.999" str= -> true } ! INCORRECT RESULT: { 999.9996e 7 3 1 f>str-rdp s" 1.000E3" str= -> true } --- 1 ---- ! redefined { \ No newline at end of file make[3]: *** [checkone] Error 1 make[3]: Leaving directory `/var/tmp/portage/dev-lang/gforth-0.7.3/work/gforth-0.7.3' make[2]: *** [gforth-fast-noll-reg] Error 2 make[2]: Leaving directory `/var/tmp/portage/dev-lang/gforth-0.7.3/work/gforth-0.7.3' make[1]: *** [optgforth-fast] Error 2 make[1]: Leaving directory `/var/tmp/portage/dev-lang/gforth-0.7.3/work/gforth-0.7.3' make[1]: Entering directory `/var/tmp/portage/dev-lang/gforth-0.7.3/work/gforth-0.7.3' [...] make checkone check-nofast ENGINE="./gforth --no-dynamic" >/dev/null 2>&1 make checkone check-nofast ENGINE="./gforth-itc" >/dev/null 2>&1 make checkone check-nofast ENGINE="./gforth-ditc" >/dev/null 2>&1 make checkone ENGINE="./gforth-fast --no-dynamic" >/dev/null 2>&1 make checkone check-nofast ENGINE="./gforth" >/dev/null 2>&1 make checkone ENGINE="./gforth-fast" >/dev/null 2>&1 *** Check successful *** ./gforth-fast --diag -e bye the gforth makefile does build the gforth engine multiple times, with different settings. It then runs the tests to find out which build works best (and which fail). Because some settings work better based on gcc-versions and architectures. I have my gforth ebuild at https://github.com/cstrotm/gforth-gentoo-ebuild I'm updating my version with the changes that you made to the ebuild. I would recommend to keep the tests in, even if one or more tests fail. I'll double check with the upstream developers that my understanding of the build-process is correct. gforh-0.7.3 does not fail any tests o x86 or amd64 here. Assuming those were fixed upstream. |