launch
CouchDB, which means changing your startup script or editing /etc/ld.so.conf
appropriately (on Linux).
Please if possible move this question to our user or dev mailing lists. This is
not a CouchDB bug.
> Running the test suite errors out with [error] [<0.348.0>] OS Proc
db/server/main.js does not
return anything.
Also the Test Suite is still failing for the basic tests.could you please help
on what else I could check
> Running the test suite errors out with [error] [<0.348.0>] OS Process Error
> <0.354.0>
> ---
library is now fixed.
> Running the test suite errors out with [error] [<0.348.0>] OS Process Error
> <0.354.0>
> -
>
> Key: COUCHDB-2255
> URL: https:/
libmozjs185
but the dynamic linker can't find that library.
You'll need to update your dynamic linker config to know where that library is
(see OS documentation) or you can set LD_LIBRARY_PATH in your environment to
include a path to the library.
> Running the test suite errors ou
/usr/local/share/couchdb/server/main.js
/usr/local/bin/couchjs: error while loading shared libraries:
libmozjs185.so.1.0: cannot open shared object file: No such file or directory
> Running the test suite errors out with [error] [<0.348.0>] OS Process Error
> <0.354.0>
>
you paste the output of ldd
/path/to/couchjs as well as trying this command: /path/to/couchjs
/path/to/main.js
> Running the test suite errors out with [error] [<0.348.0>] OS Process Erro
Ajay Gourneni created COUCHDB-2255:
--
Summary: Running the test suite errors out with [error]
[<0.348.0>] OS Process Error <0.354.0>
Key: COUCHDB-2255
URL: https://issues.apache.org/jira/browse/
Thanks, Paul. I'm using FF4.0.1 from my win7 machine to hit Futon.
One error seems to be triggered here in attachments.js:
var xhr = CouchDB.request("PUT", "/test_suite_db/bin_doc5/lorem.txt", {
headers:{"Content-Type":"text/plain;charset=utf-8"},
body:lorem
});
T(xhr.status == 201);
The actual
Jake,
What browser are you using? Officially we only support FF3.5 (unless
that version changed recently?) but the tests generally work on all
the WebKit browsers as well though occasionally they get out of whack
and someone eventually gets pissed and fixes them so we don't have to
run FF.
Beyond
Hello-
I'm new to couchdb-dev and am trying to get to the point where I can
make useful contributions. Right now 8 of my tests are failing when I
run the test suite in futon (details below).
I'm running on an Ubuntu 10.04.2 Server virtualbox, and I've forked
and cloned apache/couchdb on github a
070 is the first etap that runs the server. You could already have couchdb
running?
On Apr 10, 2010, at 3:20 PM, Noah Slater wrote:
> Hey,
>
> I backported the build fixes from 0.11.x to 0.10.x and built a package for
> the vote.
>
> I uploaded it to a Linux host to test and the test suite
Hey,
I backported the build fixes from 0.11.x to 0.10.x and built a package for the
vote.
I uploaded it to a Linux host to test and the test suite failed with a ton of
errors. I'm not going to call a vote until someone can tell me how important
they are, or what I'm doing wrong to have caused
On Fri, Mar 19, 2010 at 8:41 AM, Robert Dionne
wrote:
>
>>
>> I got the error included below this morning, and when I ran it again, there
>> was no error.
>
>> /tmp/couchdb/0.11.0/test/etap/090-task-status.ok
>> /tmp/couchdb/0.11.0/test/etap/100-ref-counter.FAILED
>
> I got the error included below this morning, and when I ran it again, there
> was no error.
> /tmp/couchdb/0.11.0/test/etap/090-task-status.ok
> /tmp/couchdb/0.11.0/test/etap/100-ref-counter.FAILED test 8
I looked into this random fail a bit
On 19 Mar 2010, at 12:05, Robert Dionne wrote:
> not really. In any event, looking at the code a bit couch_db:is_idle defines
> idle in part as "there are now only two processes referring to this db", so
> it looks like it would err on the side of concluding a db was not idle when
> in fact it
On Mar 19, 2010, at 7:48 AM, Noah Slater wrote:
> I have absolutely no problem with the time taken for the tests.
cool, I misunderstood part of your issue
>
> My only issue is that they intermittently fail. Because of that, I am now
> suspicious of any results I get.
>
> Is it really an e
I have absolutely no problem with the time taken for the tests.
My only issue is that they intermittently fail. Because of that, I am now
suspicious of any results I get.
Is it really an error, or is it a timing issue or a race condition?
Suspicious tests are next to useless.
On 19 Mar 2010, a
I see similar issues, though never with 100-ref-counter. It looks like a race
condition but should be checked because the place where it's used,
couch_db:is_idle, depends on that value being right.
make check is much faster that make cover
I think it's ok for tests to take a long time t
Some of the test suites rely on timing delays, and these are unpredictable,
resulting in non-deterministic test failures. The full tag/build/test cycle is
long enough as it is - but having to start again from scratch when the last,
and second, run of the test suite fails adds a significant amoun
19 matches
Mail list logo
