426639 - Fix the test harness to work on OS/2

Status: VERIFIED FIXED

(Testing :: XPCShell Harness, defect)

Description

[Peter Weilbacher]

This is a follow-up to bug 415947 comment 22: the test harness doesn't work on OS/2. There are two problems that I have encountered:

1. The basic problem that it xpcshell cannot easily be run from any
   directory, because it depends on several DLLs in the dist\bin (or
   dist\lib) directory: mozjs.dll, xpcom.dll, xpcomcor.dll, and nspr4.dll.
   The result is this:

     [M:\obj_fx\storage\test]make check
     ../../_tests/xpcshell-simple/test_storage/unit/test_bug-365166.js: FAIL
     ../../_tests/xpcshell-simple/test_storage/unit/test_bug-365166.js.log:
     >>>>>>>
     M:/mozilla/tools/test-harness/xpcshell-simple/test_all.sh: 
        ../../dist/bin/xpcshell: No such file or directory
  
   One needs to find a way to set BEGINLIBPATH to include (as the first
   entry) the dist\bin directory before calling xpcshell or even
   test_all.sh. (This is already done in the sign.cmd scripts in the tree.)
   A workaround is to set BEGINLIBPATH by hand before starting make check.

2. The other problem is that file paths are concatenated wrongly. Running
   make check in storage\test I get paths like 
      M:\obj_fx\storage\test\M:\mozilla\storage\test\unit\corruptDB.sqlite
   The problem seems to be in the do_get_file() function from
   test-harness/xpcshell-simple/head.js.

I don't have any good ideas for either problem yet.

Comment 1

[Peter Weilbacher]

I wonder if problem 2 has anything to do with the perhaps missing XP_OS2 in MakeAbsolutePathname() in the JS code, that I saw by chance:

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/js/src/js.c&rev=3.214&mark=3684-3686#3668

Comment 2

[(not currently active) Ted Mielczarek]

From your comments, I'm inferring that you mean the xpcshell unit test harness.

Comment 3

[Peter Weilbacher]

Attachment: fix v0.5

OK, the stuff in js.cpp that I found in comment 1 isn't used any more (it's in a part that's ifdefed NARCISSUS), but I guess one should fix that in case someone copies that code somewhere else.

The real fix for the path problem is to get NATIVE_TOPSRCDIR to have backward slashes as on Windows. That's what this patch does.

Comment 4

[Peter Weilbacher]

To be able to run "make check" I still have to

1. set BEGINLIBPATH to dist\bin before starting
2. edit test_all.sh to contain the real location of bash instead of
   /bin/bash

Not sure how to fix these problems (Walter, maybe you want to look at that?), but at least the patch let's us run most tests now. I believe it already uncovered a few problems. ;-)

Comment 5

[Walter Meinl]

(In reply to comment #4)
> To be able to run "make check" I still have to
> 
> 1. set BEGINLIBPATH to dist\bin before starting
> 2. edit test_all.sh to contain the real location of bash instead of
>    /bin/bash
I'm not sure that I made everything correctly, as I didn't observe a difference with or w/o setting BEGINLIBPATH as in 1.
I had also to edit test_all.sh and s|/bin/bash|/moztools/ash.exe| which seemed to work
> 
> Not sure how to fix these problems (Walter, maybe you want to look at that?),
Just a first thought how about writing a test_all.cmd file for OS/2, as I have no idea how to get rid of !/bin/bash in test_all.sh in such a way that other platforms are not affected. I'll have a closer look at it
> but at least the patch let's us run most tests now. I believe it already
> uncovered a few problems. ;-)
So far I see a stop in xpcom/tests and when I run the tests suggested in 
bug415947 comment 21, most test in storage/test pass but a lot of tests in the other subdirs show errors. As I built minefield with gcc-3.4.6 I encountered a lot of libc063 fff... sigsegv with xpcshell.exe.
I will rebuild with gcc-3.3.5.
Do I have to build with --enable-tests?
(I'd guess so, but the build does not complete then, it breaks in modules\plugin\sample somewhere when npupp.h is not found, manually adding it to the dist\include directory let the build go a bit further, but then it breaks again, will investigate and file a new bug about later).

Comment 6

[(not currently active) Ted Mielczarek]

You guys have a working Python, right? (presumably, since we require it for the build.) I've been trying to get someone to rewrite those test_* shell scripts in Python for a while now. They're kind of ugly, and would probably be much cleaner as Python.

Comment 7

[Walter Meinl]

With a gcc-3.3.5 build I can confirm that https://bugzilla.mozilla.org/attachment.cgi?id=355023 works. The gcc-3.4.6 libc063 crashes are due to the enablement of jit in some of the tests.
Make -C directory/test{s} check works, i.e. we don't have problems with the test_all.sh script (except the location of bash).
For me the question is how we handle the failing tests? Should we collect them somewhere (a new bug)?
In Bug 452418 it was decided to use explicitly bash (and not dash, which is a debianized version of ash) for the test scripts as the mozilla/tools/test-harness/xpcshell-simple/test_one.sh script failed with dash due to some bashisms contained in that script. However I was not able to get a test of a single file running as described in test_one.sh even when I used bash-3.1. This could be due to bugs in our bash or the parameters test_one.sh uses are wrongly resolved maybe due to the usage of drive letters, semicolons for path separators or backslashes on OS/2.
Peter, how do you want to use the test framework, do you think about automatic testing after building? Unless there is no python substitute for the shell scripts (bug 444177) we probably need a little cmd file for setting the libpath and calling sed to substitute the bash location (and back after running). I don't think that I would be able to do a real rexx substitute for test_all.sh.

Comment 8

[Walter Meinl]

(In reply to comment #7)
> In Bug 452418 it was decided to use explicitly bash (and not dash, which is a
> debianized version of ash) for the test scripts as the
> mozilla/tools/test-harness/xpcshell-simple/test_one.sh script failed with dash
> due to some bashisms contained in that script. However I was not able to get a
> test of a single file running as described in test_one.sh even when I used
> bash-3.1. This could be due to bugs in our bash or the parameters test_one.sh
> uses are wrongly resolved maybe due to the usage of drive letters, semicolons
> for path separators or backslashes on OS/2.
Ok, seems I made something wrong when I tested with test_one.sh, since after creating a \bin directory on the drive my buildsystem resides and copying bash.exe to that bin directory and setting beginlibpath also check-one and check-interactive are working.

Comment 9

[Peter Weilbacher]

If we had a short .cmd script that explicitely called
   bash <scriptname>
(and set BEGINLIBPATH) then we shouldn't have any more problems with the shebang giving a different path. I'm just not sure how to integrate that in the Makefiles.


I'm not sure how often I would run the tests. But whenever I build nightlies, I usually also build a debug build of SM (or FF). I guess that could be used to run the testsuite afterwards, but the output would need analysis which I probably won't have time to do.


(In reply to comment #6)
> You guys have a working Python, right? (presumably, since we require it for the
> build.)

Python tester scripts would help us, too, yes. (Unless they require a too new Python version that's not yet ported to or stable on OS/2.)

Comment 10

[Jeff Walden [:Waldo]]

What's the latest?  We'll be requiring 2.4 very soon.

Comment 11

[Walter Meinl]

(In reply to comment #10)
> What's the latest?  We'll be requiring 2.4 very soon.

Our latest stable version is 2.4.4. There are some 2.5.x builds out, but at the moment they don't play well with mozilla.

Comment 12

[Walter Meinl]

Attachment: v0.6 try to add an OS/2 cmd file

This is a first try for using a cmd file to call the test programs, seems to do the same as setting the shell and beginlibpath manually. I exchanged the check for $(HOST_OS_ARCH) against $(OS_ARCH), because checking for ($(HOST_OS_ARCH),os2-emx) for the newly added lines failed (probably because the removal of vacpp and emx checks recently).

Comment 13

[Walter Meinl]

Attachment: v0.7 keep it simple, invoke bash from config.mk

This does not set beginlibpath, but calls bash from config.mk.

Comment 14

[Walter Meinl]

Comment on attachment 356682 [details] [diff] [review]
v0.7 keep it simple, invoke bash from config.mk

Doesn't work when I restarted my computer and tried directly from the objdir, then it doesnt't find xpcshell.exe anymore. I wonder, if sometimes during my tests the beginlibpath is stored in the environment and then pretends I don't need to set it :-(

Comment 15

[Peter Weilbacher]

Yes, I'm not surprised. That hasn't worked here, either.

I liked attachment 356616 [details] [diff] [review] but I have a few comments on that:
- The argument parsing in that script is broken because dist and objdir
  are not actually passed as the first arguments.
- RUN_TEST_PROGRAM should be set somewhere else and not inside the
  check targets.
- test.cmd should probably be located in next to the test.sh scripts in
  the tools/test-harness/xpcshell-simple dir. Maybe called test_os2.cmd
  so that everybody knows what it's about.
- My REXX skills are very limited so I don't really know how to improve
  the parsing inside the script to get the $(DIST)/bin directory with
  backward slashes from the input that is already given. But maybe one
  could change the call so that
     RUN_TEST_PROGRAM = <path>/test.cmd $(DIST)/bin
  then the path we need _is_ the first argument.
- objdir isn't actually needed nor is it passed to the script.
- Instead of the numbered arguments one can pass "therest" to bash.exe
  (without path prefix.
- Just to be similar to the Windows part we should continue to use
  $(HOST_OS_ARCH) instead of $(OS_ARCH) (even if nobody will cross-
  compile OS/2 targets on another platform). It worked for me with
  os2-emx and although I don't know where it came from it is set to
  that in autoconf.mk (both for mozilla-1.9.1 and mozilla-central
  builds). It may be something autoconf has built in.

I have split off the minor js.cpp fix into bug 474092.

Comment 16

[Walter Meinl]

(In reply to comment #15)
> Yes, I'm not surprised. That hasn't worked here, either.
> 
> I liked attachment 356616 [details] [diff] [review] but I have a few comments on that:
> - The argument parsing in that script is broken because dist and objdir
>   are not actually passed as the first arguments.
actually, my intention to attach a script of which I knew it is in principle wrong was to get some comments, cause I am also far away from knowing rexx, thus your comments are very appreciated and give me ideas how to go on, thanks.
> - RUN_TEST_PROGRAM should be set somewhere else and not inside the
>   check targets.
Setting it in config.mk leads to problems with the cpp unit tests in xpcom (see below) 
> - test.cmd should probably be located in next to the test.sh scripts in
>   the tools/test-harness/xpcshell-simple dir. Maybe called test_os2.cmd
>   so that everybody knows what it's about.
> - My REXX skills are very limited so I don't really know how to improve
>   the parsing inside the script to get the $(DIST)/bin directory with
>   backward slashes from the input that is already given. But maybe one
>   could change the call so that
>      RUN_TEST_PROGRAM = <path>/test.cmd $(DIST)/bin
>   then the path we need _is_ the first argument.
> - objdir isn't actually needed nor is it passed to the script.
> - Instead of the numbered arguments one can pass "therest" to bash.exe
>   (without path prefix.
Ah, that's nice
> - Just to be similar to the Windows part we should continue to use
>   $(HOST_OS_ARCH) instead of $(OS_ARCH) (even if nobody will cross-
>   compile OS/2 targets on another platform). It worked for me with
>   os2-emx and although I don't know where it came from it is set to
>   that in autoconf.mk (both for mozilla-1.9.1 and mozilla-central
>   builds). It may be something autoconf has built in.
Yes, the reason, why it failed in my first attempts was probably the same as in comment #14. I'm not yet sure why, but it seems to make a difference if one runs make check after building or the other day in an already finished build directory :-(

There is another problem coming up when one sets the script to RUN_TEST_PROGRAM, the cpp tests in xpcom are also invoked by make check (when you run make check from the toplevel objdir you won't come so far down, because several xpshell tests fail and then it simply stops because of exit_on_error). However the cpp tests are invoked when running make -k check from the xpcom directory. With all scripts I tested I run into the problem that the cpp tests are already programs, i.e. exe files, but bash tries to run them as arguments.
The two different ways of running tests shell script vs. program is probably the reason that for windows and OS/2 RUN_TEST_PROGRAM is empty.

Comment 17

[Walter Meinl]

Attachment: this seems to do it

contains the rules.mk changes of fix v0.5. RUN_TEST_PROGRAM is defined in config.mk for os/2.
I had to do some changes to the xpcom/tests/Makefile.in
Problem 1 is that TestVersionCompartor gets defined parameters from a perl script. Starting an OS/2 rexx cmd file as RUN_TEST_PROGRAM inbetween appends parameters to the perl parameters and then an error occurs. Even when I manipulate the rexx cmd file to exit immediately it will spit out the path it was invoked from or override the perl parameters with an empty string. So I invented the RUN_PERL_TEST_PROGRAM variable that is set to nothing on OS/2 and to $RUN_TEST_PROGRAM for the other platforms.
Problem 2 was that the xpidl compiles a test header in the srcdir, when grep is invoked for checking the header it doesn't find it.
Will post a separate patch for the rexx file

Comment 18

[Walter Meinl]

Attachment: together with that rexx script

The script checks first if the second parsed parameter is a file with a name starting with test_  (test_all.sh and test_one.sh are the bash scripts for the xpcshell tests), if that's _not_ the case it will change the slashes to backslashes to invoke the TEST*.exe file, if it is test_{one,all}.sh it starts bash and all the rest is handled over to bash. Note, that bash must be in the path, I didn't want to hardcode it, but usually on OS/2 building systems /usr/bin should be added to the path by setmozenv.cmd anyway. When you run make -k check from the objdir, you should be able to run all cpp and xpcshell unit tests (at least when compiled with gcc3.3.5) even if some xpcshell tests may fail, you'll get a log but make runs further to the next test. However, one test is problematic as it stalls forever (DosWaitChild rc = 128): _test/xpcshell-simple/test_update/unit/test_0110_general.js tries to simulate a complete mar update which is probably not possible on OS/2. In order to run a complete make check I moved it out of the directory.
We should probably open a bug to not build the updater at all on OS/2.

Comment 19

[Walter Meinl]

Attachment: oop together with that (!) script

oops, that's the script I wanted to add.

Comment 20

[Walter Meinl]

Comment on attachment 359905 [details] [diff] [review]
this seems to do it

Argh, this works only  with firefox, with a seamonkey build I see in the mozilla dir
[E:\mozbuild3\mozilla\xpcom\tests]set BEGINLIBPATH=..\..\DIST\bin;E:\usr\local433\lib;E:\usr\lib;E:\GLIBIDL\gcc335\lib;E:\PERL\lib;E:\MOZTOOLS;D:\EMX\dll;E:\PYTHON244; 

[E:\mozbuild3\mozilla\xpcom\tests]set LIBPATHSTRICT=T 

[E:\mozbuild3\mozilla\xpcom\tests]BASH E:/usr/src/hg/comm-central/mozilla/testing/xpcshell/test_all.sh ../../dist/bin/xpcshell E:/usr/src/hg/comm-central/mozilla E:\usr\src\hg\comm-central\mozilla ../../_tests/xpcshell-simple/xpcom/unit 
TEST-UNEXPECTED-FAIL | ../../_tests/xpcshell-simple/xpcom/unit/test_bug121341.js | test failed, see log
../../_tests/xpcshell-simple/xpcom/unit/test_bug121341.js.log:
>>>>>>>
failed to get nsJSRuntimeService!

Comment 21

[Walter Meinl]

Attachment: patch for {rules,config}.mk mozilla part

Comment 22

[Walter Meinl]

Attachment: patch for {rules,config}.mk comm-central part

Comment 23

[Walter Meinl]

Attachment: together with that rexx script - slightly improved [Checkin: Comment 38 & 47]

I added an 'exit' command in the loop, cause it sometimes tried to run the loop once again

Comment 24

[Walter Meinl]

Attachment: patch for the problematic xpcom/test/Makefile

Ok, I split the patch into several parts, the Makefile Patch here has probably to be reviewed by bsmedberg. The solution to make the perl script work is to move RUN_TEST_PROGRAM to the beginning of the line. This construct works also with linux, for windows it doesn't matter because RUN_TEST_PROGRAM is not set there. I'd  guess mac would probably follow the linux line, so it should work there as well, but that I can't test.
Peter, you may want to try this part also and may suggest a reviewer for it.

Comment 25

[Walter Meinl]

(In reply to comment #20)

> failed to get nsJSRuntimeService!

Either this was due to building with gcc-4.3.3 (not yet sure about that) or I had something in my .mozconfig about enable-static. I found out, that building static interferes with the components needed by xpcshell and then the nsJSRuntimeService cannot be invoked properly because the components needed are part of the static exe.

Comment 26

[Peter Weilbacher]

Comment on attachment 360799 [details] [diff] [review]
together with that rexx script - slightly improved
[Checkin: Comment 38 & 47]

Yes, this script looks good now. But of course it depends on reviews/changes in the other patches.

Comment 27

[Peter Weilbacher]

Comment on attachment 360803 [details] [diff] [review]
patch for the problematic xpcom/test/Makefile

This somehow doesn't look right, but maybe just because I don't understand it yet.

Is the RUN_TEST_PROGRAM here the same test_os2.cmd script? Because I don't really see how that can call perl.

Comment 28

[Peter Weilbacher]

Comment on attachment 360795 [details] [diff] [review]
patch for {rules,config}.mk mozilla part

Should the $(MOZILLA_DIR) in this patch not be $(topsrcdir)?

Comment 29

[Peter Weilbacher]

Comment on attachment 360796 [details] [diff] [review]
patch for {rules,config}.mk comm-central part

Yes, this should be fine given test_os2.cmd from attachment 360799 [details] [diff] [review].

Comment 30

[Walter Meinl]

(In reply to comment #27)
> (From update of attachment 360803 [details] [diff] [review])
> This somehow doesn't look right, but maybe just because I don't understand it
> yet.
> 
> Is the RUN_TEST_PROGRAM here the same test_os2.cmd script? Because I don't
> really see how that can call perl.

Yes it's the test_os2.cmd script, it first sets beginlibpath, that's what it needed for, then jumps into the loop and calls perl (after converting the slashes to backslashes) and adds the rest of the line as the parameters. The way it is now, it tries to run the parameters of the perl script instead of passing them silently over to the versioncomparator. On linux RUN_TEST_PROGRAM is resolved to run-mozilla.sh and also only needed to set the LD_LIBRARY_PATH, it seems not to matter if it does it before or after the perl script was running, thus it works also on linux.

Comment 31

[Walter Meinl]

Attachment: patch for m-c using topsrcdir

(In reply to comment #28)
> (From update of attachment 360795 [details] [diff] [review])
> Should the $(MOZILLA_DIR) in this patch not be $(topsrcdir)?

According to rules.mk MOZILLA_DIR is set to topsrcdir (if it's else not defined). But maybe it's safer to use $(topsrcdir), someone (me?) _will_ have a strange setmozenv.cmd ;-).

Comment 32

[Walter Meinl]

Comment on attachment 360811 [details] [diff] [review]
patch for m-c using topsrcdir

oops, forgotten to ask for r

Comment 33

[Walter Meinl]

Attachment: patch for {rules,config}.mk comm-central part (context changed) [Moved to bug 484287]

context changes, apply cleanly

Comment 34

[Walter Meinl]

Attachment: patch for m-c using topsrcdir (context changes) [Checkin: Comment 39 & 48]

update due to context changes

Comment 35

[Peter Weilbacher]

Sorry that it takes me so long to review this, it looks good, but I really want to test this. I hope I'll be able to do that in the next days. If I haven't done that by Sunday, please kick me. ;-)

Comment 36

[Peter Weilbacher]

Comment on attachment 363789 [details] [diff] [review]
patch for m-c using topsrcdir (context changes)
[Checkin: Comment 39 & 48]

Still looks right to me. But as I haven't been able to complete an OS/2 build in days (machine reboots itself in between), I still haven't tested. So please find someone else to check this in.

Comment 37

[Walter Meinl]

attachment id=363789
attachment id=360799
Who checks these attachments in, please don't resolve the bug fixed yet.

Comment 38

[Serge Gautherie (:sgautherie)]

Comment on attachment 360799 [details] [diff] [review]
together with that rexx script - slightly improved
[Checkin: Comment 38 & 47]


http://hg.mozilla.org/mozilla-central/rev/abb757f6ef98

Comment 39

[Serge Gautherie (:sgautherie)]

Comment on attachment 363789 [details] [diff] [review]
patch for m-c using topsrcdir (context changes)
[Checkin: Comment 39 & 48]


http://hg.mozilla.org/mozilla-central/rev/c9107998f513

Comment 40

[Walter Meinl]

Comment on attachment 360803 [details] [diff] [review]
patch for the problematic xpcom/test/Makefile

benjamin, in order to get the tests running on OS/2 we need to run our test program (setting the beginlibpath which is equivalent to LD_LIBRARY_PATH on UNIX) _before_ starting the perl script for the testversioncomparator, since our test program creates some verbose output in addition to the output of the perl script and then the testversioncomparator fails. Running the test program (run-mozilla.sh) in advance on linux works does the right thing as well.
Secondly, I specified the target dir of the xpidl created TestScriptable.h file, because it was not found under OS/2 (how do other platform grep's find the header?)

Comment 41

[Benjamin Smedberg]

Comment on attachment 360803 [details] [diff] [review]
patch for the problematic xpcom/test/Makefile

>diff --git a/xpcom/tests/Makefile.in b/xpcom/tests/Makefile.in


>-    @if grep Notscriptable TestScriptable.h | grep -q NS_SCRIPTABLE ; then \
>+    @if grep Notscriptable $(srcdir)/TestScriptable.h | grep -q NS_SCRIPTABLE ; then \

Not clear on why you did this: TestScriptable.h should not be in the srcdir, but in the objdir (current directory)

Comment 42

[Walter Meinl]

(In reply to comment #41)
> Not clear on why you did this: TestScriptable.h should not be in the srcdir,
> but in the objdir (current directory)
Weird, on OS/2 it ends up in the srcdir, while in win it indeed is in the objdir.

Comment 43

[Walter Meinl]

Attachment: patch for the problematic xpcom/test/Makefile take 2 [Checkin: Comment 44 & 49]

ok, I think I found out, what's  going on, its xpidl.exe on OS/2 that behaves differently than that of Windows or Unix and the bug about that difference is a very old one. Will file a bug that OS/2 xpidl.exe will behave like on the other platforms. Therefore, only the change in the order with regard to the testprogram would be necessary.

Comment 44

[Serge Gautherie (:sgautherie)]

Comment on attachment 365490 [details] [diff] [review]
patch for the problematic xpcom/test/Makefile take 2
[Checkin: Comment 44 & 49]


http://hg.mozilla.org/mozilla-central/rev/b3c526cd653b

Comment 45

[Walter Meinl]

Thanks Serge --> fixed for trunk.

Comment 46

[Walter Meinl]

OS/2 only patches, partly in cross-platform files run on trunk for several weeks w/o causing problems

Comment 47

[Serge Gautherie (:sgautherie)]

Comment on attachment 360799 [details] [diff] [review]
together with that rexx script - slightly improved
[Checkin: Comment 38 & 47]


http://hg.mozilla.org/releases/mozilla-1.9.1/rev/6c32cb637dd7

Comment 48

[Serge Gautherie (:sgautherie)]

Comment on attachment 363789 [details] [diff] [review]
patch for m-c using topsrcdir (context changes)
[Checkin: Comment 39 & 48]


http://hg.mozilla.org/releases/mozilla-1.9.1/rev/a0c795d93dc2

Comment 49

[Serge Gautherie (:sgautherie)]

Comment on attachment 365490 [details] [diff] [review]
patch for the problematic xpcom/test/Makefile take 2
[Checkin: Comment 44 & 49]


http://hg.mozilla.org/releases/mozilla-1.9.1/rev/ede6e019ff42

Comment 50

[Walter Meinl]

Final request for checkin the last bits into c-c(In reply to comment #33)
attachment (id=363788) [details]

Comment 51

[Serge Gautherie (:sgautherie)]

Comment on attachment 363788 [details] [diff] [review]
patch for {rules,config}.mk comm-central part (context changed)
[Moved to bug 484287]

>+RUN_TEST_PROGRAM = $(MOZILLA_SRCDIR)/testing/xpcshell/test_os2.cmd "$(DIST)"

Aren't you changing this path in bug 484287 ?

Comment 52

[Walter Meinl]

(In reply to comment #51)
> (From update of attachment 363788 [details] [diff] [review])
> >+RUN_TEST_PROGRAM = $(MOZILLA_SRCDIR)/testing/xpcshell/test_os2.cmd "$(DIST)"
> 
> Aren't you changing this path in bug 484287 ?

Yes, but only after the change of the test scripts to python (when test_all.sh will be removed), which I don't know when or if it will happen on 1.9.1 branch. As far as I know, nobody of us builds seamonkey or thunderbird on top of trunk, at least not the few people building as well the tests.

Comment 53

[(not currently active) Ted Mielczarek]

The harness rewrite is landing on 1.9.1 ASAP. (As soon as the tree is green enough.)

Comment 54

[Walter Meinl]

(In reply to comment #53)
> The harness rewrite is landing on 1.9.1 ASAP. (As soon as the tree is green
> enough.)
Ok, Serge, I canceled the checkin-needed keyword. I 'll attach a corrected patch for c-c in bug484287. Thanks