
The OSL4-V2 test results were not updated since Feb 12. Is it possible to re-run them, or make the run periodically? Thanks, Volodya

On Feb 20, 2007, at 1:29 AM, Vladimir Prus wrote:
The OSL4-V2 test results were not updated since Feb 12. Is it possible to re-run them, or make the run periodically?
It runs nightly (as do the other OSL tests), but I'm getting this failure: ...updated 29 targets... # Searching for "process_jam_log" in "/home/user1/dgregor/ BoostRegressionTesting/boost/dist/bin"... # process_jam_log succesfully built in "/home/user1/dgregor/ BoostRegressionTesting/boost/dist/bin/process_jam_log" location Traceback (most recent call last): File "regression.py", line 1005, in ? commands[ command ]( **accept_args( args ) ) File "regression.py", line 810, in regression test( toolsets, book, bjam_options, monitored, timeout, v2, [] ) TypeError: test() takes exactly 6 arguments (7 given) Any ideas? Full log follows. Cheers, Doug # Cleaning up "/home/user1/dgregor/BoostRegressionTesting/boost" directory ... # Cleaning up "/home/user1/dgregor/BoostRegressionTesting/boost/bin" directory ... # Cleaning up "/home/user1/dgregor/BoostRegressionTesting/boost/ bin.v2" directory ... # Cleaning up "/home/user1/dgregor/BoostRegressionTesting/results" directory ... # Getting sources (2007-02-20T05:00:40Z)... # Downloading "http://engineering.meta-comm.com/boost/snapshot/boost- RC_1_34_0.tar.bz2" to "/home/user1/dgregor/BoostRegressionTesting"... # Looking for old unpacked archives... # Unpacking boost tarball ("/home/user1/dgregor/ BoostRegressionTesting/boost-RC_1_34_0.tar.bz2")... # Unpacked into directory "/home/user1/dgregor/ BoostRegressionTesting/boost-RC_1_34_0-07-02-20-0406" # Renaming "/home/user1/dgregor/BoostRegressionTesting/boost- RC_1_34_0-07-02-20-0406" into "/home/user1/dgregor/ BoostRegressionTesting/boost" # Preinstalled "/home/user1/dgregor/BoostRegressionTesting/bjam" is not found; building one... # Found "bjam" source directory "/home/user1/dgregor/ BoostRegressionTesting/boost/tools/jam/src" # Building "bjam" (./build.sh gcc)... ### ### Using 'gcc' toolset. ### rm -rf bootstrap mkdir bootstrap gcc -o bootstrap/jam0 command.c compile.c debug.c execunix.c expand.c fileunix.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c w32_getreg.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c execnt.c filent.c ./bootstrap/jam0 -f build.jam --toolset=gcc --toolset-root= clean ...found 1 target... ...updating 1 target... ...updated 1 target... ./bootstrap/jam0 -f build.jam --toolset=gcc --toolset-root= ...found 45 targets... ...updating 2 targets... [MKDIR] bin.solaris [COMPILE] bin.solaris/bjam ...updated 2 targets... # Searching for "bjam" in "/home/user1/dgregor/BoostRegressionTesting/ boost/tools/jam/src"... # bjam succesfully built in "/home/user1/dgregor/ BoostRegressionTesting/boost/tools/jam/src/bin.solaris/bjam" location # Preinstalled "/home/user1/dgregor/BoostRegressionTesting/ process_jam_log" is not found; building one... # Found "process_jam_log" source directory "/home/user1/dgregor/ BoostRegressionTesting/boost/tools/regression/build" # Building "process_jam_log" ("/home/user1/dgregor/ BoostRegressionTesting/boost/tools/jam/src/bin.solaris/bjam" --v2 "- sBOOST_BUILD_PATH=/home/user1/dgregor/BoostRegressionTesting" "- sBOOST_ROOT=/home/user1/dgregor/BoostRegressionTesting/boost" gcc)... Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (don't panic: this is a strictly optional feature). ...patience... ...found 467 targets... ...updating 29 targets... MkDir1 ../../../bin.v2 MkDir1 ../../../bin.v2/tools MkDir1 ../../../bin.v2/tools/regression MkDir1 ../../../bin.v2/tools/regression/build MkDir1 ../../../bin.v2/tools/regression/build/gcc-4.0.0 MkDir1 ../../../bin.v2/tools/regression/build/gcc-4.0.0/release MkDir1 ../../../bin.v2/tools/regression/build/gcc-4.0.0/release/link- static gcc.compile.c++ ../../../bin.v2/tools/regression/build/gcc-4.0.0/ release/link-static/process_jam_log.o gcc.compile.c++ ../../../bin.v2/tools/regression/build/gcc-4.0.0/ release/link-static/tiny_xml.o MkDir1 ../../../bin.v2/libs MkDir1 ../../../bin.v2/libs/filesystem MkDir1 ../../../bin.v2/libs/filesystem/build MkDir1 ../../../bin.v2/libs/filesystem/build/gcc-4.0.0 MkDir1 ../../../bin.v2/libs/filesystem/build/gcc-4.0.0/release MkDir1 ../../../bin.v2/libs/filesystem/build/gcc-4.0.0/release/link- static gcc.compile.c++ ../../../bin.v2/libs/filesystem/build/gcc-4.0.0/ release/link-static/exception.o gcc.compile.c++ ../../../bin.v2/libs/filesystem/build/gcc-4.0.0/ release/link-static/operations.o ../../../libs/filesystem/src/operations.cpp: In function 'boost::filesystem::system_error_type boost::filesystem::detail::dir_itr_first(void*&, void*&, const std::string&, std::string&, boost::filesystem::file_status&, boost::filesystem::file_status&)': ../../../libs/filesystem/src/operations.cpp:1210: warning: 'path_size' may be used uninitialized in this function gcc.compile.c++ ../../../bin.v2/libs/filesystem/build/gcc-4.0.0/ release/link-static/path.o gcc.compile.c++ ../../../bin.v2/libs/filesystem/build/gcc-4.0.0/ release/link-static/portability.o gcc.compile.c++ ../../../bin.v2/libs/filesystem/build/gcc-4.0.0/ release/link-static/utf8_codecvt_facet.o gcc.archive ../../../bin.v2/libs/filesystem/build/gcc-4.0.0/release/ link-static/libboost_filesystem-gcc40-1_34.a gcc.link ../../../bin.v2/tools/regression/build/gcc-4.0.0/release/ link-static/process_jam_log gcc.compile.c++ ../../../bin.v2/tools/regression/build/gcc-4.0.0/ release/link-static/compiler_status.o gcc.link ../../../bin.v2/tools/regression/build/gcc-4.0.0/release/ link-static/compiler_status MkDir1 ../../../dist MkDir1 ../../../dist/bin gcc.link ../../../dist/bin/process_jam_log gcc.link ../../../dist/bin/compiler_status ...updated 29 targets... # Searching for "process_jam_log" in "/home/user1/dgregor/ BoostRegressionTesting/boost/dist/bin"... # process_jam_log succesfully built in "/home/user1/dgregor/ BoostRegressionTesting/boost/dist/bin/process_jam_log" location Traceback (most recent call last): File "regression.py", line 1005, in ? commands[ command ]( **accept_args( args ) ) File "regression.py", line 810, in regression test( toolsets, book, bjam_options, monitored, timeout, v2, [] ) TypeError: test() takes exactly 6 arguments (7 given)

Douglas Gregor wrote:
On Feb 20, 2007, at 1:29 AM, Vladimir Prus wrote:
The OSL4-V2 test results were not updated since Feb 12. Is it possible to re-run them, or make the run periodically?
It runs nightly (as do the other OSL tests), but I'm getting this failure:
...updated 29 targets... # Searching for "process_jam_log" in "/home/user1/dgregor/ BoostRegressionTesting/boost/dist/bin"... # process_jam_log succesfully built in "/home/user1/dgregor/ BoostRegressionTesting/boost/dist/bin/process_jam_log" location Traceback (most recent call last): File "regression.py", line 1005, in ? commands[ command ]( **accept_args( args ) ) File "regression.py", line 810, in regression test( toolsets, book, bjam_options, monitored, timeout, v2, [] ) TypeError: test() takes exactly 6 arguments (7 given)
Sounds like you should get more fresh version of regression.py from RC branch. - Volodya

On 2/20/07, Vladimir Prus <ghost@cs.msu.su> wrote:
Douglas Gregor wrote:
Traceback (most recent call last): File "regression.py", line 1005, in ? commands[ command ]( **accept_args( args ) ) File "regression.py", line 810, in regression test( toolsets, book, bjam_options, monitored, timeout, v2, [] ) TypeError: test() takes exactly 6 arguments (7 given)
Sounds like you should get more fresh version of regression.py from RC branch.
I noticed the same error in my Solaris regression tests this morning. At some point, a bad copy of regression.py was in CVS. The way regression.py overwrites itself with the copy from the Boost sources can lead to this sort of failure where manual intervention is required. -- Caleb Epstein
participants (3)
-
Caleb Epstein
-
Douglas Gregor
-
Vladimir Prus