[jira] [Resolved] (COUCHDB-1404) How to password protect couchdb web interface (futon)?

[Robert Newson (Resolved) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COUCHDB-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Newson resolved COUCHDB-1404.


Resolution: Not A Problem

JIRA is for reporting bugs, not for support.

Please see our documentation at:

http://guide.couchdb.org/editions/1/en/security.html


> How to password protect couchdb web interface (futon)?
> --
>
> Key: COUCHDB-1404
> URL: https://issues.apache.org/jira/browse/COUCHDB-1404
> Project: CouchDB
>  Issue Type: Bug
>  Components: Futon
>Affects Versions: 0.10.1
> Environment: Linux / Unix
>Reporter: arturo gomez
>
> The server is running the following version of couchdb:
> {"couchdb":"Welcome","version":"0.10.1"}
> And currently the futon web interface can be accessed by the public. Is there 
> a way of password protecting the futon web interface? Would it be possible to 
> use an htpasswd file using htaccess?
> I look forward to hearing from you soon. Thanks

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (COUCHDB-1404) How to password protect couchdb web interface (futon)?

[arturo gomez (Created) (JIRA)]

How to password protect couchdb web interface (futon)?
--

 Key: COUCHDB-1404
 URL: https://issues.apache.org/jira/browse/COUCHDB-1404
 Project: CouchDB
  Issue Type: Bug
  Components: Futon
Affects Versions: 0.10.1
 Environment: Linux / Unix
Reporter: arturo gomez


The server is running the following version of couchdb:
{"couchdb":"Welcome","version":"0.10.1"}

And currently the futon web interface can be accessed by the public. Is there a 
way of password protecting the futon web interface? Would it be possible to use 
an htpasswd file using htaccess?

I look forward to hearing from you soon. Thanks



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

CouchDB Meetup Berlin

[Jan Lehnardt]

Hey all,

just a quick heads up if you are in or near Berlin. We are 
running a CouchDB Meetup tomorrow night. All details are
on lanyrd:

  http://lanyrd.com/2012/couchdb-meetup-berlin-february/

If you want to give a talk, we'd have time for one or two
more (30 minutes), let me know off-list.

See you there! :)

Cheers
Jan
-- 

Re: Order of document ids vs order of _changes ids

[Nick North]

Thank you - that answers the question perfectly. Makes my life more
complex, but more interesting.

Nick

On 7 February 2012 16:11, Robert Newson  wrote:

> The replicator replicates in parallel, so even if this property held,
> replication will violate it. There is no transactional boundary
> greater than a single document update.
>
> B.
>
> On 7 February 2012 16:03, Nick North  wrote:
> > I have a question about the order in which documents are committed to the
> > database, which I hope a knowledgeable dev can help me out with.
> >
> > The question is (I think): if I create documents, using CouchDb-assigned
> > document ids, will they appear in the _changes feed in the order that the
> > ids were assigned? For example, if the id generation algorithm
> successively
> > supplies ids aa, bb, cc, will the changes feed contain aa, bb, cc in that
> > order, or could a document with a later id "overtake" an earlier one in
> the
> > process of being committed to the database to yield, say, aa, cc, bb? A
> > secondary question is: if the order is preserved, can that be relied on
> in
> > future CouchDb versions, or is it coincidental and may change one day?
> >
> > A bit of background might help, and may possibly suggest that I'm not
> > asking the right question. I have a set of mutually replicating databases
> > which have a CouchDb id generation algorithm that produces monotonic
> > increasing globally unique document ids (details
> > here).
> > I'd like to be certain that, if document id xx has been replicated from
> one
> > database to another, then all documents that are replicated later have
> > higher ids than xx. It struck me that this might not be the case if
> > multiple simultaneous document creations are processed concurrently and
> get
> > their document ids assigned early in the process - then a small document
> > with a later id might be processed more quickly than a large one with an
> > earlier id and get into the database first.
> >
> > Any insights would be very much appreciated. Many thanks,
> >
> > Nick
>

Re: Issues blocking 1.2.0 release

[Noah Slater]

Old thread is old. But the new code works. Thanks.

On Mon, Jan 23, 2012 at 4:45 PM, Filipe David Manana wrote:

> On Mon, Jan 23, 2012 at 5:54 AM, Noah Slater  wrote:
> > Yep, that seems reasonable. Let me know when I can test again. :)
>
> Done. Can you test again?
>

Re: Order of document ids vs order of _changes ids

[Robert Newson]

The replicator replicates in parallel, so even if this property held,
replication will violate it. There is no transactional boundary
greater than a single document update.

B.

On 7 February 2012 16:03, Nick North  wrote:
> I have a question about the order in which documents are committed to the
> database, which I hope a knowledgeable dev can help me out with.
>
> The question is (I think): if I create documents, using CouchDb-assigned
> document ids, will they appear in the _changes feed in the order that the
> ids were assigned? For example, if the id generation algorithm successively
> supplies ids aa, bb, cc, will the changes feed contain aa, bb, cc in that
> order, or could a document with a later id "overtake" an earlier one in the
> process of being committed to the database to yield, say, aa, cc, bb? A
> secondary question is: if the order is preserved, can that be relied on in
> future CouchDb versions, or is it coincidental and may change one day?
>
> A bit of background might help, and may possibly suggest that I'm not
> asking the right question. I have a set of mutually replicating databases
> which have a CouchDb id generation algorithm that produces monotonic
> increasing globally unique document ids (details
> here).
> I'd like to be certain that, if document id xx has been replicated from one
> database to another, then all documents that are replicated later have
> higher ids than xx. It struck me that this might not be the case if
> multiple simultaneous document creations are processed concurrently and get
> their document ids assigned early in the process - then a small document
> with a later id might be processed more quickly than a large one with an
> earlier id and get into the database first.
>
> Any insights would be very much appreciated. Many thanks,
>
> Nick

Order of document ids vs order of _changes ids

[Nick North]

I have a question about the order in which documents are committed to the
database, which I hope a knowledgeable dev can help me out with.

The question is (I think): if I create documents, using CouchDb-assigned
document ids, will they appear in the _changes feed in the order that the
ids were assigned? For example, if the id generation algorithm successively
supplies ids aa, bb, cc, will the changes feed contain aa, bb, cc in that
order, or could a document with a later id "overtake" an earlier one in the
process of being committed to the database to yield, say, aa, cc, bb? A
secondary question is: if the order is preserved, can that be relied on in
future CouchDb versions, or is it coincidental and may change one day?

A bit of background might help, and may possibly suggest that I'm not
asking the right question. I have a set of mutually replicating databases
which have a CouchDb id generation algorithm that produces monotonic
increasing globally unique document ids (details
here).
I'd like to be certain that, if document id xx has been replicated from one
database to another, then all documents that are replicated later have
higher ids than xx. It struck me that this might not be the case if
multiple simultaneous document creations are processed concurrently and get
their document ids assigned early in the process - then a small document
with a later id might be processed more quickly than a large one with an
earlier id and get into the database first.

Any insights would be very much appreciated. Many thanks,

Nick

Re: CouchDb 1.2.0 Windows binaries issues

[Nick North]

Dave Cottlehuber suggested running the tests in Private Browsing mode,
which seems to help, as does running them one at a time.

Nick

On 7 February 2012 15:18, Bryan Green  wrote:

> Good to hear.  I have the same issues trying the test-suite with 1.1.1 on
> Windows 7 with Firefox 10.
>
> On Tue, Feb 7, 2012 at 9:07 AM, Nick North  wrote:
>
> > Apologies to everyone: I sent the same message today as I sent a couple
> of
> > days ago. What I meant to say today was that I have now also tested on
> > Windows Server 2008 R2 and the Futon tests are all behaving fine there,
> but
> > they have to be nursed through a little. That makes me think that the
> > previous errors on Win7 and Win8 may be avoidable with some care in
> running
> > the Futon test suite.
> >
> > Nick
> >
>

Re: CouchDb 1.2.0 Windows binaries issues

[Bryan Green]

Good to hear.  I have the same issues trying the test-suite with 1.1.1 on
Windows 7 with Firefox 10.

On Tue, Feb 7, 2012 at 9:07 AM, Nick North  wrote:

> Apologies to everyone: I sent the same message today as I sent a couple of
> days ago. What I meant to say today was that I have now also tested on
> Windows Server 2008 R2 and the Futon tests are all behaving fine there, but
> they have to be nursed through a little. That makes me think that the
> previous errors on Win7 and Win8 may be avoidable with some care in running
> the Futon test suite.
>
> Nick
>

Re: CouchDb 1.2.0 Windows binaries issues

[Nick North]

Apologies to everyone: I sent the same message today as I sent a couple of
days ago. What I meant to say today was that I have now also tested on
Windows Server 2008 R2 and the Futon tests are all behaving fine there, but
they have to be nursed through a little. That makes me think that the
previous errors on Win7 and Win8 may be avoidable with some care in running
the Futon test suite.

Nick

[jira] [Resolved] (COUCHDB-1402) Crash on Views - {'EXIT', {{badmatch, {error, {enoent, [{erlang,open_port,

[Robert Newson (Resolved) (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COUCHDB-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Newson resolved COUCHDB-1402.


Resolution: Not A Problem

> Crash on Views - {'EXIT', {{badmatch, {error, {enoent, [{erlang,open_port,
> --
>
> Key: COUCHDB-1402
> URL: https://issues.apache.org/jira/browse/COUCHDB-1402
> Project: CouchDB
>  Issue Type: Bug
>  Components: Database Core
>Affects Versions: 1.1.1
> Environment: Windows Server 2003 R2 SP3
>Reporter: Christopher Betz
>
> Every time I go to access a view, I get this error, even from futon. I am 
> currently running Windows 2003 Server R3, SP3. 
> ** Reason for termination ==
> ** {'EXIT',
> {{badmatch,
> {error,
> {enoent,
> [{erlang,open_port,
> [{spawn,
> "c:/PROGRA~1/Apache Software 
> Foundation/CouchDB/lib/couch-1.1.1/priv/couchspawnkillable ./couchjs.exe 
> ../share/couchdb/server/main.js"},
> [stream,{line,1024},binary,exit_status,hide]]},
> {couch_os_process,init,1},
> {gen_server,init_it,6},
> {proc_lib,init_p_do_apply,3}]}}},
> [{couch_query_servers,new_process,3},
> {couch_query_servers,lang_proc,3},
> {couch_query_servers,handle_call,3},
> {gen_server,handle_msg,5},
> {proc_lib,init_p_do_apply,3}]}}
> [Mon, 06 Feb 2012 18:59:17 GMT] [error] [<0.19625.0>] {error_report,<0.34.0>,
> {<0.19625.0>,crash_report,
> [[{initial_call,{couch_file,init,['Argument__1']}},
> {pid,<0.19625.0>},
> {registered_name,[]},
> {error_info,
> {exit,
> {'EXIT',
> {{badmatch,
> {error,
> {enoent,
> [{erlang,open_port,
> [{spawn,
> "c:/PROGRA~1/Apache Software 
> Foundation/CouchDB/lib/couch-1.1.1/priv/couchspawnkillable ./couchjs.exe 
> ../share/couchdb/server/main.js"},
> [stream,
> {line,1024},
> binary,exit_status,hide]]},
> {couch_os_process,init,1},
> {gen_server,init_it,6},
> {proc_lib,init_p_do_apply,3}]}}},
> [{couch_query_servers,new_process,3},
> {couch_query_servers,lang_proc,3},
> {couch_query_servers,handle_call,3},
> {gen_server,handle_msg,5},
> {proc_lib,init_p_do_apply,3}]}},
> [{gen_server,terminate,6},
> {proc_lib,init_p_do_apply,3}]}},
> {ancestors,[<0.19624.0>,<0.19623.0>]},
> {messages,[{'EXIT',<0.19627.0>,shutdown}]},
> {links,[]},
> {dictionary,[]},
> {trap_exit,true},
> {status,running},
> {heap_size,987},
> {stack_size,24},
> {reductions,1331}],
> []]}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COUCHDB-1402) Crash on Views - {'EXIT', {{badmatch, {error, {enoent, [{erlang,open_port,

[Christopher Betz (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202443#comment-13202443
 ] 

Christopher Betz commented on COUCHDB-1402:
---

I installed to C:\Apache\CouchDB and it works! Thank you!

> Crash on Views - {'EXIT', {{badmatch, {error, {enoent, [{erlang,open_port,
> --
>
> Key: COUCHDB-1402
> URL: https://issues.apache.org/jira/browse/COUCHDB-1402
> Project: CouchDB
>  Issue Type: Bug
>  Components: Database Core
>Affects Versions: 1.1.1
> Environment: Windows Server 2003 R2 SP3
>Reporter: Christopher Betz
>
> Every time I go to access a view, I get this error, even from futon. I am 
> currently running Windows 2003 Server R3, SP3. 
> ** Reason for termination ==
> ** {'EXIT',
> {{badmatch,
> {error,
> {enoent,
> [{erlang,open_port,
> [{spawn,
> "c:/PROGRA~1/Apache Software 
> Foundation/CouchDB/lib/couch-1.1.1/priv/couchspawnkillable ./couchjs.exe 
> ../share/couchdb/server/main.js"},
> [stream,{line,1024},binary,exit_status,hide]]},
> {couch_os_process,init,1},
> {gen_server,init_it,6},
> {proc_lib,init_p_do_apply,3}]}}},
> [{couch_query_servers,new_process,3},
> {couch_query_servers,lang_proc,3},
> {couch_query_servers,handle_call,3},
> {gen_server,handle_msg,5},
> {proc_lib,init_p_do_apply,3}]}}
> [Mon, 06 Feb 2012 18:59:17 GMT] [error] [<0.19625.0>] {error_report,<0.34.0>,
> {<0.19625.0>,crash_report,
> [[{initial_call,{couch_file,init,['Argument__1']}},
> {pid,<0.19625.0>},
> {registered_name,[]},
> {error_info,
> {exit,
> {'EXIT',
> {{badmatch,
> {error,
> {enoent,
> [{erlang,open_port,
> [{spawn,
> "c:/PROGRA~1/Apache Software 
> Foundation/CouchDB/lib/couch-1.1.1/priv/couchspawnkillable ./couchjs.exe 
> ../share/couchdb/server/main.js"},
> [stream,
> {line,1024},
> binary,exit_status,hide]]},
> {couch_os_process,init,1},
> {gen_server,init_it,6},
> {proc_lib,init_p_do_apply,3}]}}},
> [{couch_query_servers,new_process,3},
> {couch_query_servers,lang_proc,3},
> {couch_query_servers,handle_call,3},
> {gen_server,handle_msg,5},
> {proc_lib,init_p_do_apply,3}]}},
> [{gen_server,terminate,6},
> {proc_lib,init_p_do_apply,3}]}},
> {ancestors,[<0.19624.0>,<0.19623.0>]},
> {messages,[{'EXIT',<0.19627.0>,shutdown}]},
> {links,[]},
> {dictionary,[]},
> {trap_exit,true},
> {status,running},
> {heap_size,987},
> {stack_size,24},
> {reductions,1331}],
> []]}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

CouchDb 1.2.0 Windows binaries issues

[Nick North]

I've just got to try the 1.2.0 Windows binaries at
http://people.apache.org/~dch/dist/snapshots/20120127/ on Windows 7 and
Windows 8 Preview and hit a few initial issues with the Futon test
suite which seem worth feeding back to the list.

1. If you upgrade an existing instance by uninstalling, then installing
1.2.0 (i.e. you keep any existing users), and the original instance had
admin users, then the Verify Installation tool in Futon returns X: [object
Object] if you are not logged in as an admin. It would be more useful if it
detected the problem and gave a pop-up to tell you to log in as an admin.

2. The replication test fails when you run the tests through on a clean
install, with a "file exists" error. However, it succeeds on rerunning.

3. The replicator_db test fails in a variety of ways. On the first run it
fails with:

1. Assertion failed: copy === null
2. Assertion failed: expected 'null', got
'{"_id":"foo666","_rev":"1-8f008c4354eb07d5fbfc399a84bc88a1","value":666}'

on subsequent runs it fails with things like:

Assertion failed: expected '"fdmanana"', got 'null'

and then leaves me logged in as user joe. Eventually it seems to settle to
giving:

1. Assertion failed: copy === null
2. Assertion failed: copy === null
3. Assertion failed: expected 'null', got '{"_id":"foo666","_rev":"1
-8f008c4354eb07d5fbfc399a84bc88a1","value":666}'

However, the behaviour does vary enough that I only consider the foo666
error to be a properly reportable issue.


Do other people get these errors, or are they peculiar to my setup? In
particular the replicator_db test is very odd in its lack of
consistency. Thanks,

Nick North

PS Tests were run using Firefox 10.0.

[jira] [Commented] (COUCHDB-1402) Crash on Views - {'EXIT', {{badmatch, {error, {enoent, [{erlang,open_port,

[Dave Cottlehuber (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202414#comment-13202414
 ] 

Dave Cottlehuber commented on COUCHDB-1402:
---

the path is odd - c:/PROGRA~1/Apache Software Foundation - mix of 8.3 and full 
path. Not sure how this would happen though.

I'm travelling ATM so can't look further but can you install into (say) a 
non-spaces path & try again?


> Crash on Views - {'EXIT', {{badmatch, {error, {enoent, [{erlang,open_port,
> --
>
> Key: COUCHDB-1402
> URL: https://issues.apache.org/jira/browse/COUCHDB-1402
> Project: CouchDB
>  Issue Type: Bug
>  Components: Database Core
>Affects Versions: 1.1.1
> Environment: Windows Server 2003 R2 SP3
>Reporter: Christopher Betz
>
> Every time I go to access a view, I get this error, even from futon. I am 
> currently running Windows 2003 Server R3, SP3. 
> ** Reason for termination ==
> ** {'EXIT',
> {{badmatch,
> {error,
> {enoent,
> [{erlang,open_port,
> [{spawn,
> "c:/PROGRA~1/Apache Software 
> Foundation/CouchDB/lib/couch-1.1.1/priv/couchspawnkillable ./couchjs.exe 
> ../share/couchdb/server/main.js"},
> [stream,{line,1024},binary,exit_status,hide]]},
> {couch_os_process,init,1},
> {gen_server,init_it,6},
> {proc_lib,init_p_do_apply,3}]}}},
> [{couch_query_servers,new_process,3},
> {couch_query_servers,lang_proc,3},
> {couch_query_servers,handle_call,3},
> {gen_server,handle_msg,5},
> {proc_lib,init_p_do_apply,3}]}}
> [Mon, 06 Feb 2012 18:59:17 GMT] [error] [<0.19625.0>] {error_report,<0.34.0>,
> {<0.19625.0>,crash_report,
> [[{initial_call,{couch_file,init,['Argument__1']}},
> {pid,<0.19625.0>},
> {registered_name,[]},
> {error_info,
> {exit,
> {'EXIT',
> {{badmatch,
> {error,
> {enoent,
> [{erlang,open_port,
> [{spawn,
> "c:/PROGRA~1/Apache Software 
> Foundation/CouchDB/lib/couch-1.1.1/priv/couchspawnkillable ./couchjs.exe 
> ../share/couchdb/server/main.js"},
> [stream,
> {line,1024},
> binary,exit_status,hide]]},
> {couch_os_process,init,1},
> {gen_server,init_it,6},
> {proc_lib,init_p_do_apply,3}]}}},
> [{couch_query_servers,new_process,3},
> {couch_query_servers,lang_proc,3},
> {couch_query_servers,handle_call,3},
> {gen_server,handle_msg,5},
> {proc_lib,init_p_do_apply,3}]}},
> [{gen_server,terminate,6},
> {proc_lib,init_p_do_apply,3}]}},
> {ancestors,[<0.19624.0>,<0.19623.0>]},
> {messages,[{'EXIT',<0.19627.0>,shutdown}]},
> {links,[]},
> {dictionary,[]},
> {trap_exit,true},
> {status,running},
> {heap_size,987},
> {stack_size,24},
> {reductions,1331}],
> []]}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COUCHDB-1402) Crash on Views - {'EXIT', {{badmatch, {error, {enoent, [{erlang,open_port,

[Christopher Betz (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202317#comment-13202317
 ] 

Christopher Betz commented on COUCHDB-1402:
---

Thanks for the reply! I downloaded and installed this specific version: 
setup-couchdb-1.1.1_js185_otp_R14B03+fix-win32-crypto.exe. I tried uninstalling 
and reinstalling on 2 different machines to no avail. 

I've confirmed that the files listed above exist:

C:\Program Files\Apache Software 
Foundation\CouchDB\lib\couch-1.1.1\priv\couchspawnkillable.exe
C:\Program Files\Apache Software Foundation\CouchDB\bin\couchjs.exe
C:\Program Files\Apache Software Foundation\CouchDB\share\couchdb\server\main.js

Any other thoughts? Thanks again!

> Crash on Views - {'EXIT', {{badmatch, {error, {enoent, [{erlang,open_port,
> --
>
> Key: COUCHDB-1402
> URL: https://issues.apache.org/jira/browse/COUCHDB-1402
> Project: CouchDB
>  Issue Type: Bug
>  Components: Database Core
>Affects Versions: 1.1.1
> Environment: Windows Server 2003 R2 SP3
>Reporter: Christopher Betz
>
> Every time I go to access a view, I get this error, even from futon. I am 
> currently running Windows 2003 Server R3, SP3. 
> ** Reason for termination ==
> ** {'EXIT',
> {{badmatch,
> {error,
> {enoent,
> [{erlang,open_port,
> [{spawn,
> "c:/PROGRA~1/Apache Software 
> Foundation/CouchDB/lib/couch-1.1.1/priv/couchspawnkillable ./couchjs.exe 
> ../share/couchdb/server/main.js"},
> [stream,{line,1024},binary,exit_status,hide]]},
> {couch_os_process,init,1},
> {gen_server,init_it,6},
> {proc_lib,init_p_do_apply,3}]}}},
> [{couch_query_servers,new_process,3},
> {couch_query_servers,lang_proc,3},
> {couch_query_servers,handle_call,3},
> {gen_server,handle_msg,5},
> {proc_lib,init_p_do_apply,3}]}}
> [Mon, 06 Feb 2012 18:59:17 GMT] [error] [<0.19625.0>] {error_report,<0.34.0>,
> {<0.19625.0>,crash_report,
> [[{initial_call,{couch_file,init,['Argument__1']}},
> {pid,<0.19625.0>},
> {registered_name,[]},
> {error_info,
> {exit,
> {'EXIT',
> {{badmatch,
> {error,
> {enoent,
> [{erlang,open_port,
> [{spawn,
> "c:/PROGRA~1/Apache Software 
> Foundation/CouchDB/lib/couch-1.1.1/priv/couchspawnkillable ./couchjs.exe 
> ../share/couchdb/server/main.js"},
> [stream,
> {line,1024},
> binary,exit_status,hide]]},
> {couch_os_process,init,1},
> {gen_server,init_it,6},
> {proc_lib,init_p_do_apply,3}]}}},
> [{couch_query_servers,new_process,3},
> {couch_query_servers,lang_proc,3},
> {couch_query_servers,handle_call,3},
> {gen_server,handle_msg,5},
> {proc_lib,init_p_do_apply,3}]}},
> [{gen_server,terminate,6},
> {proc_lib,init_p_do_apply,3}]}},
> {ancestors,[<0.19624.0>,<0.19623.0>]},
> {messages,[{'EXIT',<0.19627.0>,shutdown}]},
> {links,[]},
> {dictionary,[]},
> {trap_exit,true},
> {status,running},
> {heap_size,987},
> {stack_size,24},
> {reductions,1331}],
> []]}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Problems blocking 1.2.0 release

[Jan Lehnardt]

On Feb 7, 2012, at 12:50 , Noah Slater wrote:

> On Mon, Feb 6, 2012 at 7:04 PM, Jan Lehnardt  wrote:
>> 
>> I'd suggest this looks like we are not using mochiweb.app.src at all
>> and we could either delete it or keep to keep file-parity with upstream.
>> 
>> (file-parity interlude, I'd prefer to keep upstream directories in as
>> much of the original shape as possible to make upgrades more obvious
>> and less error prone)
> 
> 
> Keep.
> 
> 
> Only in 1.2.0/src/mochiweb: mochiweb_request_tests.erl
>>> 
>>> This can probably be deleted outright assuming make check doesn't try
>>> and use it (and I don't think it does).
>> 
>> File-parity. I'd say we keep it.
> 
> 
> Keep.
> 
 Only in apache-couchdb-1.2.0/src/snappy: Makefile.in
>>> 
>>> No idea what this business is. An artefact of the snappy build? Just
>> delete it?
>> 
>> Makefile.in gets generated by ./bootstrap and is used by ./configure
>> to produce Makefile. We should absolutely keep this and put it in
>> EXTRA_DIST.
> 
> 
> My error, this is actually fine and doesn't need modification.
> 
> 
> Only in 1.2.0/src/snappy/google-snappy: AUTHORS
>>> 
>>> EXTRA_DIST? Delete?
>> 
>> File-parity. I'd say we keep it.
> 
> 
> My gut tells me we should remove this, but I'm not sure. I can see your
> arguments. What have we done in the past? I can't remember. Do any of the
> other libraries we bundle include documentation files in the source that we
> have removed?

I don't think we have a strict policy (aside from licensing and NOTICE
guidelines) and whoever was responsible for bringing in a library did
whatever they felt like.

I just know from updating a few libraries to newer versions over time
that being diligent about pruning files strictly not needed made the
update process a bit more tedious. Hence my suggestion to make it easier
for future us's.

Cheers
Jan
-- 



> 
> 
> Only in 1.2.0/src/snappy/google-snappy: COPYING
>>> 
>>> We should look on whether we keep this or not. There's probably ASF
>>> guidelines on what to do here. I'm guessing either delete it or add it
>>> to NOTICE in the root.
>> 
>> NOTICE carries the ASF mandated entry for Snappy, so we are covered on
>> that end. The other question is file-parity again, I'd say we keep it.
> 
> 
> Same point.
> 
> 
> Only in apache-couchdb-1.2.0/src/snappy/google-snappy:
> snappy-stubs-public.h
>>> 
>>> Not sure why this is made by bootstrap. Might be a valid reason, might
>>> just need the generation to happen during make instead.
>> 
>> It looks like it makes some assumptions about types. I'm not the expert
>> but assuming the values the packager puts in are the same for everybody
>> is dangerous at best. So yes, I agree, a Make-ification is in order.
>> Can we fix this upstream (a brief search didn't suggest any existing
>> solutions).
>> 
> 
> Per your follow up, we should not ship this. Agreed.

Re: Problems blocking 1.2.0 release

[Noah Slater]

On Mon, Feb 6, 2012 at 7:04 PM, Jan Lehnardt  wrote:
>
> I'd suggest this looks like we are not using mochiweb.app.src at all
> and we could either delete it or keep to keep file-parity with upstream.
>
> (file-parity interlude, I'd prefer to keep upstream directories in as
>  much of the original shape as possible to make upgrades more obvious
>  and less error prone)


Keep.


> >>> Only in 1.2.0/src/mochiweb: mochiweb_request_tests.erl
> >
> > This can probably be deleted outright assuming make check doesn't try
> > and use it (and I don't think it does).
>
> File-parity. I'd say we keep it.


Keep.

>>> Only in apache-couchdb-1.2.0/src/snappy: Makefile.in
> >
> > No idea what this business is. An artefact of the snappy build? Just
> delete it?
>
> Makefile.in gets generated by ./bootstrap and is used by ./configure
> to produce Makefile. We should absolutely keep this and put it in
> EXTRA_DIST.


My error, this is actually fine and doesn't need modification.


> >>> Only in 1.2.0/src/snappy/google-snappy: AUTHORS
> >
> > EXTRA_DIST? Delete?
>
> File-parity. I'd say we keep it.


My gut tells me we should remove this, but I'm not sure. I can see your
arguments. What have we done in the past? I can't remember. Do any of the
other libraries we bundle include documentation files in the source that we
have removed?


> >>> Only in 1.2.0/src/snappy/google-snappy: COPYING
> >
> > We should look on whether we keep this or not. There's probably ASF
> > guidelines on what to do here. I'm guessing either delete it or add it
> > to NOTICE in the root.
>
> NOTICE carries the ASF mandated entry for Snappy, so we are covered on
> that end. The other question is file-parity again, I'd say we keep it.


Same point.


> >>> Only in apache-couchdb-1.2.0/src/snappy/google-snappy:
> >>> snappy-stubs-public.h
> >
> > Not sure why this is made by bootstrap. Might be a valid reason, might
> > just need the generation to happen during make instead.
>
> It looks like it makes some assumptions about types. I'm not the expert
> but assuming the values the packager puts in are the same for everybody
> is dangerous at best. So yes, I agree, a Make-ification is in order.
> Can we fix this upstream (a brief search didn't suggest any existing
> solutions).
>

Per your follow up, we should not ship this. Agreed.

Re: Problems blocking 1.2.0 release

[Jan Lehnardt]

On Feb 6, 2012, at 20:04 , Jan Lehnardt wrote:

> 
> On Feb 4, 2012, at 02:43 , Paul Davis wrote:
> 
>> Doing some traveling but quick thoughts inline:
>> 
>> On Fri, Feb 3, 2012 at 6:29 PM, Noah Slater  wrote:
>>> Hello,
>>> 
>>> I have a 1.2.0 release ready to go, but there are a few problems that need
>>> fixing before I am prepared to ship.
>>> 
>>> Comparing our source to the release artefact, I get:
>>> 
>>> Only in 1.2.0/src/mochiweb: mochiweb.app.src
>> 
>> IIRC, I think I noticed that we're not generating a mochiweb.app from
>> this file. It needs to be there and we need to generate it and there's
>> a pattern. Just needs a rule in the make file and an EXTRA_DIST entry
>> for the .app I think.
> 
> Makefile.am has:
> 
>   %.app: %.app.in
>   cp $< $@
> 
> I'd suggest this looks like we are not using mochiweb.app.src at all
> and we could either delete it or keep to keep file-parity with upstream.
> 
> (file-parity interlude, I'd prefer to keep upstream directories in as
> much of the original shape as possible to make upgrades more obvious
> and less error prone)
> 
 Only in 1.2.0/src/mochiweb: mochiweb_request_tests.erl
>> 
>> This can probably be deleted outright assuming make check doesn't try
>> and use it (and I don't think it does).
> 
> File-parity. I'd say we keep it.
> 
> 
 Only in apache-couchdb-1.2.0/src/snappy: Makefile.in
>> 
>> No idea what this business is. An artefact of the snappy build? Just delete 
>> it?
> 
> Makefile.in gets generated by ./bootstrap and is used by ./configure
> to produce Makefile. We should absolutely keep this and put it in EXTRA_DIST.
> 
 Only in 1.2.0/src/snappy/google-snappy: AUTHORS
>> 
>> EXTRA_DIST? Delete?
> 
> File-parity. I'd say we keep it.
> 
 Only in 1.2.0/src/snappy/google-snappy: COPYING
>> 
>> We should look on whether we keep this or not. There's probably ASF
>> guidelines on what to do here. I'm guessing either delete it or add it
>> to NOTICE in the root.
> 
> NOTICE carries the ASF mandated entry for Snappy, so we are covered on
> that end. The other question is file-parity again, I'd say we keep it.
> 
 Only in apache-couchdb-1.2.0/src/snappy/google-snappy:
 snappy-stubs-public.h
>> 
>> Not sure why this is made by bootstrap. Might be a valid reason, might
>> just need the generation to happen during make instead.
> 
> It looks like it makes some assumptions about types. I'm not the expert
> but assuming the values the packager puts in are the same for everybody
> is dangerous at best. So yes, I agree, a Make-ification is in order.
> Can we fix this upstream (a brief search didn't suggest any existing
> solutions).


In fact, snappy-stubs-public.h is produced at ./configure time by us, so
we should not ship this.

Cheers
Jan
-- 



>>> 
>>> 
>>> The only time this should ever happen is when the file is used by the
>>> bootstrap process, or Git, and can be discarded after bootstrapping.
>>> Clearly, none of these files pass that requirement. Which means that we
>>> should be shipping them in the source tarball. Probably by adding them to
>>> EXTRA_DIST or something.
>>> 
>>> For lines that start:
>>> 
>>> Only in apache-couchdb-1.2.0
>>> 
>>> 
>>> The only time this should ever happen is when the file is created by the
>>> bootstrap process, or need to be made on the assumption that our users will
>>> not be able to make them, as is the case for our man pages. Clearly, none
>>> of these files pass that requirement. Now, I checked the snappy makefile,
>>> and it looks like we're shipping these generated files on purpose, which is
>>> very strange.
>>> 
>>> So, over to you, Paul, I guess. Want to weigh in on these? They need fixing
>>> on master as well as the release branch.
>>> 
>>> Thanks,
>>> 
>>> N
> 

[jira] [Commented] (COUCHDB-1402) Crash on Views - {'EXIT', {{badmatch, {error, {enoent, [{erlang,open_port,

[James Howe (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202197#comment-13202197
 ] 

James Howe commented on COUCHDB-1402:
-

ENOENT is basically file not found. Looks like you've not installed couchdb 
correctly and one of couchspawnkillable, couchjs.exe or main.js aren't in the 
right place.

Windows installers can be found here if you're having trouble.
https://github.com/dch/couchdb/downloads

> Crash on Views - {'EXIT', {{badmatch, {error, {enoent, [{erlang,open_port,
> --
>
> Key: COUCHDB-1402
> URL: https://issues.apache.org/jira/browse/COUCHDB-1402
> Project: CouchDB
>  Issue Type: Bug
>  Components: Database Core
>Affects Versions: 1.1.1
> Environment: Windows Server 2003 R2 SP3
>Reporter: Christopher Betz
>
> Every time I go to access a view, I get this error, even from futon. I am 
> currently running Windows 2003 Server R3, SP3. 
> ** Reason for termination ==
> ** {'EXIT',
> {{badmatch,
> {error,
> {enoent,
> [{erlang,open_port,
> [{spawn,
> "c:/PROGRA~1/Apache Software 
> Foundation/CouchDB/lib/couch-1.1.1/priv/couchspawnkillable ./couchjs.exe 
> ../share/couchdb/server/main.js"},
> [stream,{line,1024},binary,exit_status,hide]]},
> {couch_os_process,init,1},
> {gen_server,init_it,6},
> {proc_lib,init_p_do_apply,3}]}}},
> [{couch_query_servers,new_process,3},
> {couch_query_servers,lang_proc,3},
> {couch_query_servers,handle_call,3},
> {gen_server,handle_msg,5},
> {proc_lib,init_p_do_apply,3}]}}
> [Mon, 06 Feb 2012 18:59:17 GMT] [error] [<0.19625.0>] {error_report,<0.34.0>,
> {<0.19625.0>,crash_report,
> [[{initial_call,{couch_file,init,['Argument__1']}},
> {pid,<0.19625.0>},
> {registered_name,[]},
> {error_info,
> {exit,
> {'EXIT',
> {{badmatch,
> {error,
> {enoent,
> [{erlang,open_port,
> [{spawn,
> "c:/PROGRA~1/Apache Software 
> Foundation/CouchDB/lib/couch-1.1.1/priv/couchspawnkillable ./couchjs.exe 
> ../share/couchdb/server/main.js"},
> [stream,
> {line,1024},
> binary,exit_status,hide]]},
> {couch_os_process,init,1},
> {gen_server,init_it,6},
> {proc_lib,init_p_do_apply,3}]}}},
> [{couch_query_servers,new_process,3},
> {couch_query_servers,lang_proc,3},
> {couch_query_servers,handle_call,3},
> {gen_server,handle_msg,5},
> {proc_lib,init_p_do_apply,3}]}},
> [{gen_server,terminate,6},
> {proc_lib,init_p_do_apply,3}]}},
> {ancestors,[<0.19624.0>,<0.19623.0>]},
> {messages,[{'EXIT',<0.19627.0>,shutdown}]},
> {links,[]},
> {dictionary,[]},
> {trap_exit,true},
> {status,running},
> {heap_size,987},
> {stack_size,24},
> {reductions,1331}],
> []]}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira