[jira] [Updated] (COUCHDB-1824) Official documentation of replication algorithm?
[ https://issues.apache.org/jira/browse/COUCHDB-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Chesneau updated COUCHDB-1824: - Priority: Minor (was: Major) > Official documentation of replication algorithm? > > > Key: COUCHDB-1824 > URL: https://issues.apache.org/jira/browse/COUCHDB-1824 > Project: CouchDB > Issue Type: Bug > Components: Documentation >Reporter: Nathan Vander Wilt >Priority: Minor > > Though it's in some ways an internal detail, it might be nice to provide a > canonical description of CouchDB's replication protocol (algorithm, really) > in the documentation. See links at: > http://wiki.apache.org/couchdb/Replication#Protocol_Documentation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1824) Official documentation of replication algorithm?
[ https://issues.apache.org/jira/browse/COUCHDB-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Chesneau updated COUCHDB-1824: - Issue Type: Documentation (was: Bug) > Official documentation of replication algorithm? > > > Key: COUCHDB-1824 > URL: https://issues.apache.org/jira/browse/COUCHDB-1824 > Project: CouchDB > Issue Type: Documentation > Components: Documentation >Reporter: Nathan Vander Wilt >Priority: Minor > > Though it's in some ways an internal detail, it might be nice to provide a > canonical description of CouchDB's replication protocol (algorithm, really) > in the documentation. See links at: > http://wiki.apache.org/couchdb/Replication#Protocol_Documentation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1824) Official documentation of replication algorithm?
[ https://issues.apache.org/jira/browse/COUCHDB-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Chesneau updated COUCHDB-1824: - Priority: Major (was: Minor) > Official documentation of replication algorithm? > > > Key: COUCHDB-1824 > URL: https://issues.apache.org/jira/browse/COUCHDB-1824 > Project: CouchDB > Issue Type: Documentation > Components: Documentation >Reporter: Nathan Vander Wilt > > Though it's in some ways an internal detail, it might be nice to provide a > canonical description of CouchDB's replication protocol (algorithm, really) > in the documentation. See links at: > http://wiki.apache.org/couchdb/Replication#Protocol_Documentation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1824) Official documentation of replication algorithm?
[ https://issues.apache.org/jira/browse/COUCHDB-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13688977#comment-13688977 ] Benoit Chesneau commented on COUCHDB-1824: -- [~dch]I'm interested to work on this one. I opened a thread on G+ (that should be mirrored on the ml probably...) > Official documentation of replication algorithm? > > > Key: COUCHDB-1824 > URL: https://issues.apache.org/jira/browse/COUCHDB-1824 > Project: CouchDB > Issue Type: Documentation > Components: Documentation >Reporter: Nathan Vander Wilt > > Though it's in some ways an internal detail, it might be nice to provide a > canonical description of CouchDB's replication protocol (algorithm, really) > in the documentation. See links at: > http://wiki.apache.org/couchdb/Replication#Protocol_Documentation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
couchdb replication algorithm
Hi all, I've written sometimes ago for another usage a document describing the replication algorithm in pseudo-code: https://github.com/refuge/rcouch/wiki/Replication-Algorithm Utltimately this document would allow me to write an alternative replicator to couchdb that would work with any kind of storages. Hopefully someone can help me to fix the errors and provide some basic implementation either in Go or Python (for readability). It can als be completed with the excellent doc of +Jens Alfke : https://github.com/couchbase/couchbase-lite-ios/wiki/Replication-Algorithm or the one in dataprotocols: http://www.dataprotocols.org/en/latest/couchdb_replication.html Any help is appreciated on that topic. Also at the end I think this document would allow to close the Jira issue: https://issues.apache.org/jira/browse/COUCHDB-1824 - benoit
R16B01 + Homebrew, Archlinux etc
Hi folks, Currently Couch is holding back installation on OS X of things like Elixir (needs >= R16B) because we don't yet support that. What's the best way (from our perspective) of sorting this out? Some ideas: 1. a special 1.4.0 release that only support R15B+ is 1.3.1 + the changes that are only on master at the moment ( 1696-update-mochiweb-2-4-2 branch). 2. providing homebrew with a .patch file that sits on top of 1.3.1 release, using a backport approach like macports does (1696-backport-mochiweb-2-4-2-1.3.x branch). 3. a stable 1.3.1+R16B-backport fork for homebrew with the same fix as #2.. I would be ok to maintain that until the next master-based release if required. (1696-backport-mochiweb-2-4-2-1.3.x branch again). This would be fine for homebrew team I think. Would this work for other platforms that tend to use a current Erlang? Note that the 2.4.2 mochiweb is the *last* release that still supports < R15B, and it's already at 2.6.0. Upgrading past v2.4.2 bring us fixes related to tcp error handling differences between between R14/15/16: https://github.com/mochi/mochiweb/commit/56a32a0cc091b69374f35aa0787c36c7776ae816 any opinion on whether this should be included too? A+ Dave
Re: R16B01 + Homebrew, Archlinux etc
On Thu, Jun 20, 2013 at 12:12 PM, Dave Cottlehuber wrote: > 1. a special 1.4.0 release that only support R15B+ is 1.3.1 + the > changes that are only on master at the moment ( > 1696-update-mochiweb-2-4-2 branch). "Special" releases sounds... not good. > 2. providing homebrew with a .patch file that sits on top of 1.3.1 > release, using a backport approach like macports does > (1696-backport-mochiweb-2-4-2-1.3.x branch). That sure seems like a fine approach. > 3. a stable 1.3.1+R16B-backport fork for homebrew with the same fix as > #2.. I would be ok to maintain that until the next master-based > release if required. > (1696-backport-mochiweb-2-4-2-1.3.x branch again). This would be fine > for homebrew team I think. I don't see how this is very different from #2. > Note that the 2.4.2 mochiweb is the *last* release that still supports > < R15B, and it's already at 2.6.0. So can we do 2.6.0 mochiweb for 1.4.0? Cheers, Dirkjan
BigCouch IP clearance (Was: Re: Summary of IRC meeting in #couchdb-meeting, Wed Jun 19 19:05:16 2013)
Here's the clearance file: http://incubator.apache.org/ip-clearance/couchdb-bigcouch.html > "Check and make sure that the files that have been donated have been updated to reflect the new ASF copyright. " I saw something mentioned about this on IRC. Jan suggested we just make the change while importing the code into a Git branch. I take it this has been done, as the date has been filled in on the clearance form. Only section we need to complete is: > Verify distribution rights Looks like all of that can be checked off immediately, no? After doing that and committing back to Subversion, should be as simple as posting a lazy consensus thread to gene...@incubator.org and waiting three days. On 19 June 2013 20:43, ASF IRC Services wrote: > Members present: benoitc, drsm79, wendall911, Kxepal, chewbranca, Wohali > > > Meeting summary: > > > 1. Preface > a. Kxepal to get finally the cloak (Wohali, 1) > > 2. 1.3.1 release > a. nslater to ship 1.3.1 release (Kxepal, 2) > b. nslater to ship 1.3.1 release (Wohali, 2) > > 3. fauxton > a. https://gist.github.com/chewbranca/5816534 (Kxepal, 3) > b. people to comment on chewbranca's fauxton and replicator commands in > JIRA or the ML (Wohali, 3) > > 4. rcouch merge > a. benoitc to propose vote for rcouch merge with short digest about > rcouch features (Kxepal, 4) > > 5. bigcouch ip clearance > > 6. docs > a. kxepal to finish configuration, installation and administration > guides for docs and describe query server and replication protocols > (Kxepal, 6) > > > > Actions: > > - Kxepal to get finally the cloak (Wohali, 19:05:21) > - nslater to ship 1.3.1 release (Kxepal, 19:06:17) > - nslater to ship 1.3.1 release (Wohali, 19:06:29) > - people to comment on chewbranca's fauxton and replicator commands in > JIRA or the ML (Wohali, 19:14:01) > - benoitc to propose vote for rcouch merge with short digest about rcouch > features (Kxepal, 19:26:12) > - kxepal to finish configuration, installation and administration guides > for docs and describe query server and replication protocols (Kxepal, > 19:38:16) > > IRC log follows: > > > # 1. Preface # > 19:05:21 [Wohali]: #action Kxepal to get finally the cloak > 19:05:28 [Kxepal]: woo..magic! > > > # 2. 1.3.1 release # > 19:05:54 [Wohali]: plz to vote, myself included > 19:06:01 [Kxepal]: Noah is on vacantions now, but everything is ready to > ship (mac and windows builds) > 19:06:06 [Wohali]: excellent > 19:06:17 [Kxepal]: #action nslater to ship 1.3.1 release > 19:06:29 [Wohali]: #action nslater to ship 1.3.1 release > 19:06:36 [Wohali]: (dunno if it listens to you yet :( ) > 19:07:01 [Kxepal]: [offtopic] afaik actions and links aren't requires karma > 19:07:58 [Kxepal]: tilgovi isn't there to ask about deb package - afaik he > wanted to make it, but not sure > 19:08:17 [Kxepal]: ok, moving forward > > > # 3. fauxton # > 19:08:42 [Kxepal]: wee (: > 19:08:55 [Kxepal]: sorry > 19:09:18 [Kxepal]: chewbranca just mailed about Fauxton Tidings > 19:09:21 [Kxepal]: #link https://gist.github.com/chewbranca/5816534 > 19:09:33 [drsm79]: good work chewbranca :) > 19:09:49 [Wohali]: hooray russell > 19:10:02 [drsm79]: should people feedback via JIRA (assume yes)? > 19:10:21 [Kxepal]: awesome! didn't read detailed yet (will do it after > meeting), but looks really wonderful > 19:10:24 [Wohali]: my only comment i sthat deprecation of _replicate > should be no sooner than 2.0 > 19:10:49 [Wohali]: i guess it could be deprecated but not removed now. > 19:11:24 [Kxepal]: it's bikesheding question since one shot replications > will pollute replicator db in this case, but it's good to raise it one more > time in ML > 19:11:24 [drsm79]: +1 > 19:11:31 [Wohali]: indeed > 19:12:02 [Kxepal]: afaik rnewson is working on alternative solution for > clouldant: https://github.com/cloudant/couch_replicator > 19:12:41 [Wohali]: that's just a new implementation of the same api iirc > 19:12:46 [Kxepal]: it's also very interesting implementation to look on > (per user's replicator database) > 19:13:11 [Wohali]: yeah, the original design has some serious security > issues when taken in the light of multitenancy. > 19:14:01 [Wohali]: #action people to comment on chewbranca's fauxton and > replicator commands in JIRA or the ML > 19:15:16 [drsm79]: we should probably get sue (deathbear) along to these > in the future > 19:15:28 [drsm79]: she's done a lot of the fauxton code > 19:17:58 [Wohali]: ok, what's next > 19:18:11 [Kxepal]: drsm79: great! hope it will be soon (: > > > # 4. rcouch merge # > 19:18:36 [Kxepal]: benoitc: are you there? > 19:19:39 [benoitc]: mostly > 19:20:36 [Kxepal]: benoitc: any plans for rcouch merge?(: > 19:21:34 [benoitc]: apparently i have to propose to a vote this merge > (though I would have prefer to just merge it as usual commits) > 19:22:25 [benoitc]: so i need to digest this indigest doc, and will > probably propose to the vote all the thing tomorrow. > 19:23:48
[jira] [Updated] (COUCHDB-907) Support multiple ip addresses in bind_address
[ https://issues.apache.org/jira/browse/COUCHDB-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin updated COUCHDB-907: - Component/s: HTTP Interface > Support multiple ip addresses in bind_address > - > > Key: COUCHDB-907 > URL: https://issues.apache.org/jira/browse/COUCHDB-907 > Project: CouchDB > Issue Type: Improvement > Components: HTTP Interface >Reporter: Mathias Gug > > It would be useful to be able to configure couchdb to listen to multiple ip > addresses in addition to one and all interfaces. > See http://comments.gmane.org/gmane.comp.db.couchdb.user/7050 for such a > request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Fauxton Tidings
I Like it very much. :-) When Fauxton will replace Futon? 1.4? On Jun 19, 2013, at 9:38 PM, Russell Branca wrote: > Looks like I tried to get too fancy with embedding dropbox images. Here's > public urls viewable on dropbox.com: > > all dbs: https://www.dropbox.com/s/0plfvfcwtaod0sz/Fauxton_all_dbs.png > > all docs and views: > https://www.dropbox.com/s/7aws0xmw4pdkrck/Fauxton_all_docs.png > > view editor: > https://www.dropbox.com/s/ob7z9glbuopifo1/Fauxton_index_view_adv_options.png > > code editor: > https://www.dropbox.com/s/trc7150otb27xbb/Fauxton_code_editor.png > > > -Russell
[jira] [Updated] (COUCHDB-412) CouchDB fails to start when log file is a pipe
[ https://issues.apache.org/jira/browse/COUCHDB-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin updated COUCHDB-412: - Component/s: Logging > CouchDB fails to start when log file is a pipe > -- > > Key: COUCHDB-412 > URL: https://issues.apache.org/jira/browse/COUCHDB-412 > Project: CouchDB > Issue Type: Bug > Components: Logging >Affects Versions: 0.9 > Environment: CentOS x86_64 >Reporter: Enda Farrell > Attachments: COUCHDB_412_01.patch, pipe_wrapper.sh > > > I have an 0.9 CouchDB. When the local.ini file's [log] file is actually a > pipe (with a known to be running consumer) rather than a file, CouchDB fails > to start. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (COUCHDB-656) Futon IE8 Caching Issue
[ https://issues.apache.org/jira/browse/COUCHDB-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin closed COUCHDB-656. Resolution: Fixed It looks to be fixed in [a18aec2|https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=a18aec2] for 0.11.1 release. > Futon IE8 Caching Issue > --- > > Key: COUCHDB-656 > URL: https://issues.apache.org/jira/browse/COUCHDB-656 > Project: CouchDB > Issue Type: Bug > Components: Futon >Affects Versions: 0.10, 0.10.1, 0.11 >Reporter: Andrew Alexander > > Under IE8, Futon has a caching issue that prevents the page from updating > whenever chages are made, this can confirmed by turning on the developers > tools and selecting Always Refresh From Server, which makes the problem go > away. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-622) erlview sandboxing via parse transform
[ https://issues.apache.org/jira/browse/COUCHDB-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin updated COUCHDB-622: - Component/s: View Server Support > erlview sandboxing via parse transform > -- > > Key: COUCHDB-622 > URL: https://issues.apache.org/jira/browse/COUCHDB-622 > Project: CouchDB > Issue Type: Improvement > Components: View Server Support >Reporter: Brian Candler >Priority: Minor > > I'm just adding this ticket so I don't forget about it. > It's possible to improve the safety of the native erlang view server, just by > doing a simple walk of the parsed abstract form. I think all we need to do is > forbid calls to functions in all external modules m:f(), except for > whitelisted modules (e.g. io_lib, lists) or specific functions. We also need > a whitelist of BIFs. > Some care may be needed for imported functions - check if they are already > expanded to m:f() in the abstract form, or remain as f(). > My main concern is preventing things like os:cmd(). There are also many > possible DoS attacks, like atom exhaustion or spawning infinite numbers of > processes. However, most view definitions aren't going to need spawn() or > list_to_atom(). A configurable whitelist could be very tight by default, but > still allow admins to allow any specific functions they need. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-519) Continous Integration links on website
[ https://issues.apache.org/jira/browse/COUCHDB-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689188#comment-13689188 ] Alexander Shorin commented on COUCHDB-519: -- Bump. [~janl], may be also add link to Jenkins? > Continous Integration links on website > -- > > Key: COUCHDB-519 > URL: https://issues.apache.org/jira/browse/COUCHDB-519 > Project: CouchDB > Issue Type: Improvement > Components: Documentation >Reporter: Paul Joseph Davis >Assignee: Paul Joseph Davis > > Add links to the buildbot CI to the website. > Links of interest: > http://ci.apache.org/waterfall?show_events=false&branch=&builder=couchdb-trunk&builder=couchdb-coverage&reload=60 > http://ci.apache.org/waterfall/help > http://ci.apache.org/projects/couchdb/cover/index.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (COUCHDB-546) cookie_auth test fails when the client doesn't send cookies
[ https://issues.apache.org/jira/browse/COUCHDB-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin closed COUCHDB-546. Resolution: Fixed Fixed in [e15698f|https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=e15698f743f9b7013afbbba90acd4d45de72ca2b] > cookie_auth test fails when the client doesn't send cookies > --- > > Key: COUCHDB-546 > URL: https://issues.apache.org/jira/browse/COUCHDB-546 > Project: CouchDB > Issue Type: Bug > Components: Test Suite >Reporter: Paul Joseph Davis > > I noticed this when working on refactoring couchjs's curl bindings. It > doesn't send cookies by default, which means its authenticated no matter what > as cookie auth fail falls back to normal auth which isn't setup by the test. > I tried adding an admin to the run_on_modified_server settings but there are > quite a few calls that required auth being set so it broke and I left it > after adding cookie support to the client. > Note to future self to figure out how to test this. Might need a "don't send > cookies" flag to the CouchHTTP XHR object I wrote that would only be set when > run from make check as I'm not sure what browsers have in the way of support > here. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Fauxton Tidings
On Wed, Jun 19, 2013 at 9:38 PM, Russell Branca wrote: > Looks like I tried to get too fancy with embedding dropbox images. Here's > public urls viewable on dropbox.com: > > all dbs: https://www.dropbox.com/s/0plfvfcwtaod0sz/Fauxton_all_dbs.png > > all docs and views: > https://www.dropbox.com/s/7aws0xmw4pdkrck/Fauxton_all_docs.png > > view editor: > https://www.dropbox.com/s/ob7z9glbuopifo1/Fauxton_index_view_adv_options.png > > code editor: > https://www.dropbox.com/s/trc7150otb27xbb/Fauxton_code_editor.png Looking pretty awesome! Like Filippo, I'm curious to hear if you have an approximate ETA for landing this on master. Cheers, Dirkjan
Re: BigCouch IP clearance (Was: Re: Summary of IRC meeting in #couchdb-meeting, Wed Jun 19 19:05:16 2013)
On Jun 20, 2013, at 13:55 , Noah Slater wrote: > Here's the clearance file: > > http://incubator.apache.org/ip-clearance/couchdb-bigcouch.html > >> "Check and make sure that the files that have been donated have been > updated to reflect the new ASF copyright. " > > I saw something mentioned about this on IRC. Jan suggested we just make the > change while importing the code into a Git branch. I take it this has been > done, as the date has been filled in on the clearance form. > > Only section we need to complete is: > >> Verify distribution rights > > Looks like all of that can be checked off immediately, no? > > After doing that and committing back to Subversion, should be as simple as > posting a lazy consensus thread to gene...@incubator.org and waiting three > days. +1 > > > > On 19 June 2013 20:43, ASF IRC Services wrote: > >> Members present: benoitc, drsm79, wendall911, Kxepal, chewbranca, Wohali >> >> >> Meeting summary: >> >> >> 1. Preface >> a. Kxepal to get finally the cloak (Wohali, 1) >> >> 2. 1.3.1 release >> a. nslater to ship 1.3.1 release (Kxepal, 2) >> b. nslater to ship 1.3.1 release (Wohali, 2) >> >> 3. fauxton >> a. https://gist.github.com/chewbranca/5816534 (Kxepal, 3) >> b. people to comment on chewbranca's fauxton and replicator commands in >> JIRA or the ML (Wohali, 3) >> >> 4. rcouch merge >> a. benoitc to propose vote for rcouch merge with short digest about >> rcouch features (Kxepal, 4) >> >> 5. bigcouch ip clearance >> >> 6. docs >> a. kxepal to finish configuration, installation and administration >> guides for docs and describe query server and replication protocols >> (Kxepal, 6) >> >> >> >> Actions: >> >> - Kxepal to get finally the cloak (Wohali, 19:05:21) >> - nslater to ship 1.3.1 release (Kxepal, 19:06:17) >> - nslater to ship 1.3.1 release (Wohali, 19:06:29) >> - people to comment on chewbranca's fauxton and replicator commands in >> JIRA or the ML (Wohali, 19:14:01) >> - benoitc to propose vote for rcouch merge with short digest about rcouch >> features (Kxepal, 19:26:12) >> - kxepal to finish configuration, installation and administration guides >> for docs and describe query server and replication protocols (Kxepal, >> 19:38:16) >> >> IRC log follows: >> >> >> # 1. Preface # >> 19:05:21 [Wohali]: #action Kxepal to get finally the cloak >> 19:05:28 [Kxepal]: woo..magic! >> >> >> # 2. 1.3.1 release # >> 19:05:54 [Wohali]: plz to vote, myself included >> 19:06:01 [Kxepal]: Noah is on vacantions now, but everything is ready to >> ship (mac and windows builds) >> 19:06:06 [Wohali]: excellent >> 19:06:17 [Kxepal]: #action nslater to ship 1.3.1 release >> 19:06:29 [Wohali]: #action nslater to ship 1.3.1 release >> 19:06:36 [Wohali]: (dunno if it listens to you yet :( ) >> 19:07:01 [Kxepal]: [offtopic] afaik actions and links aren't requires karma >> 19:07:58 [Kxepal]: tilgovi isn't there to ask about deb package - afaik he >> wanted to make it, but not sure >> 19:08:17 [Kxepal]: ok, moving forward >> >> >> # 3. fauxton # >> 19:08:42 [Kxepal]: wee (: >> 19:08:55 [Kxepal]: sorry >> 19:09:18 [Kxepal]: chewbranca just mailed about Fauxton Tidings >> 19:09:21 [Kxepal]: #link https://gist.github.com/chewbranca/5816534 >> 19:09:33 [drsm79]: good work chewbranca :) >> 19:09:49 [Wohali]: hooray russell >> 19:10:02 [drsm79]: should people feedback via JIRA (assume yes)? >> 19:10:21 [Kxepal]: awesome! didn't read detailed yet (will do it after >> meeting), but looks really wonderful >> 19:10:24 [Wohali]: my only comment i sthat deprecation of _replicate >> should be no sooner than 2.0 >> 19:10:49 [Wohali]: i guess it could be deprecated but not removed now. >> 19:11:24 [Kxepal]: it's bikesheding question since one shot replications >> will pollute replicator db in this case, but it's good to raise it one more >> time in ML >> 19:11:24 [drsm79]: +1 >> 19:11:31 [Wohali]: indeed >> 19:12:02 [Kxepal]: afaik rnewson is working on alternative solution for >> clouldant: https://github.com/cloudant/couch_replicator >> 19:12:41 [Wohali]: that's just a new implementation of the same api iirc >> 19:12:46 [Kxepal]: it's also very interesting implementation to look on >> (per user's replicator database) >> 19:13:11 [Wohali]: yeah, the original design has some serious security >> issues when taken in the light of multitenancy. >> 19:14:01 [Wohali]: #action people to comment on chewbranca's fauxton and >> replicator commands in JIRA or the ML >> 19:15:16 [drsm79]: we should probably get sue (deathbear) along to these >> in the future >> 19:15:28 [drsm79]: she's done a lot of the fauxton code >> 19:17:58 [Wohali]: ok, what's next >> 19:18:11 [Kxepal]: drsm79: great! hope it will be soon (: >> >> >> # 4. rcouch merge # >> 19:18:36 [Kxepal]: benoitc: are you there? >> 19:19:39 [benoitc]: mostly >> 19:20:36 [Kxepal]: benoitc: any plans for rcouch merge?(: >> 19:21:34 [benoitc]: apparently i have to propose t
[jira] [Closed] (COUCHDB-540) oauth_token_users seems to be in the wrong place
[ https://issues.apache.org/jira/browse/COUCHDB-540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin closed COUCHDB-540. Resolution: Fixed Fix Version/s: 1.2 I'd like to close this issue by next reasons: 1) In the recent CouchDB releases (1.2.0+) it's possible to setup OAuth credentials within _users database. See an example usage on [wiki|http://wiki.apache.org/couchdb/Link_Collection_Authentication_and_Authorization#couch_httpd_oauth::oauth_authentication_handler] and COUCHDB-1238 issue for more info. 2) For older releases it's possible to keep such information within /etc/couchdb/local.d/*.ini configuration files, splitting OAuth credentials from main CouchDB configuration. > oauth_token_users seems to be in the wrong place > > > Key: COUCHDB-540 > URL: https://issues.apache.org/jira/browse/COUCHDB-540 > Project: CouchDB > Issue Type: Bug > Components: Infrastructure >Affects Versions: 0.10 > Environment: Ubuntu Linux >Reporter: Chris Jones > Fix For: 1.2 > > > If one has many users, the oath_token_users section of /etc/couchdb/local.ini > becomes quite large. This: > a) makes legitimate configuration of the server less friendly > b) makes the file extremely hard to manage via version control > c) is probably a violation of the FHS. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-359) group_level should be rejected when a single key is specified
[ https://issues.apache.org/jira/browse/COUCHDB-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin updated COUCHDB-359: - Component/s: View Server Support > group_level should be rejected when a single key is specified > - > > Key: COUCHDB-359 > URL: https://issues.apache.org/jira/browse/COUCHDB-359 > Project: CouchDB > Issue Type: Bug > Components: View Server Support >Reporter: Mark Hammond > > As noted in COUCHDB-357, couch correctly rejects a multikey fetch when > group_level is specified (although the error message is misleading). > group_level should be similarly rejected when a single-key fetch is used - > currently is is accepted but returns incorrect results. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-801) Add 'ForceReReduce=true' option to views to ensure that reduce function is called
[ https://issues.apache.org/jira/browse/COUCHDB-801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin updated COUCHDB-801: - Component/s: View Server Support > Add 'ForceReReduce=true' option to views to ensure that reduce function is > called > - > > Key: COUCHDB-801 > URL: https://issues.apache.org/jira/browse/COUCHDB-801 > Project: CouchDB > Issue Type: Improvement > Components: View Server Support > Environment: Any >Reporter: Bryan White >Priority: Minor > Labels: map, reduce, rereduce > > AFAIK there is no way to force a Map Reduce with rereduce=true to happen, > other than creating an arbitrary large number of documents. So any bugs in > handling reduce calls with rereduce=true might not be discovered at > development time. > I propose something like a 'ForceReReduce=true' option which will call Reduce > with rereduce=true (either once overall, or maybe once for each document) in > order to shake any lurking bugs out of the tree. > If there *is* such a feature, I apologise; I've looked but can't find it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (COUCHDB-649) Users are unable to login to futon when require_valid_user is set to true
[ https://issues.apache.org/jira/browse/COUCHDB-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin closed COUCHDB-649. Resolution: Fixed Fixed in [6121e10|https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=6121e10adfe0095247852565d860d99590be213e] > Users are unable to login to futon when require_valid_user is set to true > - > > Key: COUCHDB-649 > URL: https://issues.apache.org/jira/browse/COUCHDB-649 > Project: CouchDB > Issue Type: Bug > Components: Futon >Reporter: Ben Schwarz >Assignee: Chris Anderson >Priority: Minor > Labels: login > > Using basic auth to login to futon doesn't work. A cookie is required. > This presents an annoying / difficult user experience. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: BigCouch IP clearance (Was: Re: Summary of IRC meeting in #couchdb-meeting, Wed Jun 19 19:05:16 2013)
Yup, I believe we can tick those off. I did update the page as I've been through and fixed all the copyright header goop now. B. On 20 June 2013 13:54, Jan Lehnardt wrote: > > On Jun 20, 2013, at 13:55 , Noah Slater wrote: > >> Here's the clearance file: >> >> http://incubator.apache.org/ip-clearance/couchdb-bigcouch.html >> >>> "Check and make sure that the files that have been donated have been >> updated to reflect the new ASF copyright. " >> >> I saw something mentioned about this on IRC. Jan suggested we just make the >> change while importing the code into a Git branch. I take it this has been >> done, as the date has been filled in on the clearance form. >> >> Only section we need to complete is: >> >>> Verify distribution rights >> >> Looks like all of that can be checked off immediately, no? >> >> After doing that and committing back to Subversion, should be as simple as >> posting a lazy consensus thread to gene...@incubator.org and waiting three >> days. > > +1 > > >> >> >> >> On 19 June 2013 20:43, ASF IRC Services wrote: >> >>> Members present: benoitc, drsm79, wendall911, Kxepal, chewbranca, Wohali >>> >>> >>> Meeting summary: >>> >>> >>> 1. Preface >>> a. Kxepal to get finally the cloak (Wohali, 1) >>> >>> 2. 1.3.1 release >>> a. nslater to ship 1.3.1 release (Kxepal, 2) >>> b. nslater to ship 1.3.1 release (Wohali, 2) >>> >>> 3. fauxton >>> a. https://gist.github.com/chewbranca/5816534 (Kxepal, 3) >>> b. people to comment on chewbranca's fauxton and replicator commands in >>> JIRA or the ML (Wohali, 3) >>> >>> 4. rcouch merge >>> a. benoitc to propose vote for rcouch merge with short digest about >>> rcouch features (Kxepal, 4) >>> >>> 5. bigcouch ip clearance >>> >>> 6. docs >>> a. kxepal to finish configuration, installation and administration >>> guides for docs and describe query server and replication protocols >>> (Kxepal, 6) >>> >>> >>> >>> Actions: >>> >>> - Kxepal to get finally the cloak (Wohali, 19:05:21) >>> - nslater to ship 1.3.1 release (Kxepal, 19:06:17) >>> - nslater to ship 1.3.1 release (Wohali, 19:06:29) >>> - people to comment on chewbranca's fauxton and replicator commands in >>> JIRA or the ML (Wohali, 19:14:01) >>> - benoitc to propose vote for rcouch merge with short digest about rcouch >>> features (Kxepal, 19:26:12) >>> - kxepal to finish configuration, installation and administration guides >>> for docs and describe query server and replication protocols (Kxepal, >>> 19:38:16) >>> >>> IRC log follows: >>> >>> >>> # 1. Preface # >>> 19:05:21 [Wohali]: #action Kxepal to get finally the cloak >>> 19:05:28 [Kxepal]: woo..magic! >>> >>> >>> # 2. 1.3.1 release # >>> 19:05:54 [Wohali]: plz to vote, myself included >>> 19:06:01 [Kxepal]: Noah is on vacantions now, but everything is ready to >>> ship (mac and windows builds) >>> 19:06:06 [Wohali]: excellent >>> 19:06:17 [Kxepal]: #action nslater to ship 1.3.1 release >>> 19:06:29 [Wohali]: #action nslater to ship 1.3.1 release >>> 19:06:36 [Wohali]: (dunno if it listens to you yet :( ) >>> 19:07:01 [Kxepal]: [offtopic] afaik actions and links aren't requires karma >>> 19:07:58 [Kxepal]: tilgovi isn't there to ask about deb package - afaik he >>> wanted to make it, but not sure >>> 19:08:17 [Kxepal]: ok, moving forward >>> >>> >>> # 3. fauxton # >>> 19:08:42 [Kxepal]: wee (: >>> 19:08:55 [Kxepal]: sorry >>> 19:09:18 [Kxepal]: chewbranca just mailed about Fauxton Tidings >>> 19:09:21 [Kxepal]: #link https://gist.github.com/chewbranca/5816534 >>> 19:09:33 [drsm79]: good work chewbranca :) >>> 19:09:49 [Wohali]: hooray russell >>> 19:10:02 [drsm79]: should people feedback via JIRA (assume yes)? >>> 19:10:21 [Kxepal]: awesome! didn't read detailed yet (will do it after >>> meeting), but looks really wonderful >>> 19:10:24 [Wohali]: my only comment i sthat deprecation of _replicate >>> should be no sooner than 2.0 >>> 19:10:49 [Wohali]: i guess it could be deprecated but not removed now. >>> 19:11:24 [Kxepal]: it's bikesheding question since one shot replications >>> will pollute replicator db in this case, but it's good to raise it one more >>> time in ML >>> 19:11:24 [drsm79]: +1 >>> 19:11:31 [Wohali]: indeed >>> 19:12:02 [Kxepal]: afaik rnewson is working on alternative solution for >>> clouldant: https://github.com/cloudant/couch_replicator >>> 19:12:41 [Wohali]: that's just a new implementation of the same api iirc >>> 19:12:46 [Kxepal]: it's also very interesting implementation to look on >>> (per user's replicator database) >>> 19:13:11 [Wohali]: yeah, the original design has some serious security >>> issues when taken in the light of multitenancy. >>> 19:14:01 [Wohali]: #action people to comment on chewbranca's fauxton and >>> replicator commands in JIRA or the ML >>> 19:15:16 [drsm79]: we should probably get sue (deathbear) along to these >>> in the future >>> 19:15:28 [drsm79]: she's done a lot of the fauxton code >>> 19:17:58 [Wohali]: ok, what's next >
[jira] [Closed] (COUCHDB-864) multipart/related PUT's always close the connection.
[
https://issues.apache.org/jira/browse/COUCHDB-864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin closed COUCHDB-864.
Resolution: Fixed
Fixed in
[4e2c27d|https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=4e2c27d024d5d0353ebde7f0f72c3d22f733821d]
> multipart/related PUT's always close the connection.
>
>
> Key: COUCHDB-864
> URL: https://issues.apache.org/jira/browse/COUCHDB-864
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core
>Reporter: Robert Newson
> Attachments: chunked.erl, mp_doc_put_http_pipeline.patch,
> mp_pipeline.patch
>
>
> I noticed that mochiweb always closes the connection when doing a
> multipart/related PUT (to insert the JSON document and accompanying
> attachments in one call). Ultimately it's because we call recv(0) and not
> recv_body, thus consuming more data than we actually process. Mochiweb
> notices that there is unread data on the socket and closes the connection.
> This impacts replication with attachments, as I believe they go through this
> code path (and, thus, are forever reconnecting).
> The code below demonstrates a fix for this issue but isn't good enough for
> trunk. Adam provided the important process dictionary fix.
> ---
> src/couchdb/couch_doc.erl |1 +
> src/couchdb/couch_httpd_db.erl | 13 +
> 2 files changed, 10 insertions(+), 4 deletions(-)
> diff --git a/src/couchdb/couch_doc.erl b/src/couchdb/couch_doc.erl
> index 5009f8f..f8c874b 100644
> --- a/src/couchdb/couch_doc.erl
> +++ b/src/couchdb/couch_doc.erl
> @@ -455,6 +455,7 @@ doc_from_multi_part_stream(ContentType, DataFun) ->
> Parser ! {get_doc_bytes, self()},
> receive
> {doc_bytes, DocBytes} ->
> +erlang:put(mochiweb_request_recv, true),
> Doc = from_json_obj(?JSON_DECODE(DocBytes)),
> % go through the attachments looking for 'follows' in the data,
> % replace with function that reads the data from MIME stream.
> diff --git a/src/couchdb/couch_httpd_db.erl b/src/couchdb/couch_httpd_db.erl
> index b0fbe8d..eff7d67 100644
> --- a/src/couchdb/couch_httpd_db.erl
> +++ b/src/couchdb/couch_httpd_db.erl
> @@ -651,12 +651,13 @@ db_doc_req(#httpd{method='PUT'}=Req, Db, DocId) ->
> } = parse_doc_query(Req),
> couch_doc:validate_docid(DocId),
>
> +Len = couch_httpd:header_value(Req,"Content-Length"),
> Loc = absolute_uri(Req, "/" ++ ?b2l(Db#db.name) ++ "/" ++ ?b2l(DocId)),
> RespHeaders = [{"Location", Loc}],
> case couch_util:to_list(couch_httpd:header_value(Req, "Content-Type")) of
> ("multipart/related;" ++ _) = ContentType ->
> {ok, Doc0} = couch_doc:doc_from_multi_part_stream(ContentType,
> -fun() -> receive_request_data(Req) end),
> +fun() -> receive_request_data(Req, Len) end),
> Doc = couch_doc_from_req(Req, DocId, Doc0),
> update_doc(Req, Db, DocId, Doc, RespHeaders, UpdateType);
> _Else ->
> @@ -775,9 +776,13 @@ send_docs_multipart(Req, Results, Options) ->
> couch_httpd:send_chunk(Resp, <<"--">>),
> couch_httpd:last_chunk(Resp).
>
> -receive_request_data(Req) ->
> -{couch_httpd:recv(Req, 0), fun() -> receive_request_data(Req) end}.
> -
> +receive_request_data(Req, undefined) ->
> +receive_request_data(Req, 0);
> +receive_request_data(Req, Len) when is_list(Len)->
> +Remaining = list_to_integer(Len),
> +Bin = couch_httpd:recv(Req, Remaining),
> +{Bin, fun() -> receive_request_data(Req, Remaining - iolist_size(Bin))
> end}.
> +
> update_doc_result_to_json({{Id, Rev}, Error}) ->
> {_Code, Err, Msg} = couch_httpd:error_info(Error),
> {[{id, Id}, {rev, couch_doc:rev_to_str(Rev)},
> --
> 1.7.2.2
> Umbra
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (COUCHDB-724) Big numbers changed to decimals
[
https://issues.apache.org/jira/browse/COUCHDB-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin closed COUCHDB-724.
Resolution: Fixed
Close as fixed since I'm not able to reproduce this issue with actual CouchDB
releases: 1.2.0 (not much, but still), 1.2.2, 1.3.0 and master. Much lucky it
was eventually fixed with COUCHDB-1118 by [adding ejson
application|https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=3925e856078717a4b3c1ed58918a11cf90a758b9].
> Big numbers changed to decimals
> ---
>
> Key: COUCHDB-724
> URL: https://issues.apache.org/jira/browse/COUCHDB-724
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 0.11
> Environment: Mac OS X running
> CouchDBX-0.11.0-R13B04-64bit-Snow-Leopard
>Reporter: Matthew Sinclair-Day
>
> After upgrading from Couch 0.10.1 to 0.11.0, big integers are now being
> returned by couch as decimals. This is a change from the previous release.
> Here's a curl session demonstrating the problem:
> curl -X POST http://localhost:5984/msdtest -d '{"num":123456789123456789}'
> {"ok":true,"id":"8d211c89d80d14972af7cb93e71754bc","rev":"1-fce9e6cc4e72866f75aeadbaed1a65c9"}
> curl http://localhost:5984/msdtest/8d211c89d80d14972af7cb93e71754bc
> {"_id":"8d211c89d80d14972af7cb93e71754bc","_rev":"1-fce9e6cc4e72866f75aeadbaed1a65c9","num":123456789123456780.0}
> In Futon, the 'num' value does not have a decimal.
> It seems like the problem occurs with large numbers. Here's another curl
> where the num is not made into a decimal:
> curl -X POST http://localhost:5984/msdtest -d '{"num":123456789}'
> {"ok":true,"id":"8d211c89d80d14972af7cb93e7175daf","rev":"1-039a59b36e40b4216eac91872eed4645"}
> curl http://localhost:5984/msdtest/8d211c89d80d14972af7cb93e7175daf
> {"_id":"8d211c89d80d14972af7cb93e7175daf","_rev":"1-039a59b36e40b4216eac91872eed4645","num":123456789}
> Here's a session from 0.10.1 demonstrating the problem did not exist in that
> release:
> curl -X POST http://localhost:5984/msdtest -d '{"num":123456789123456789}'
> {"ok":true,"id":"fcd6d8fca421023581a608758a0abe35","rev":"1-fce9e6cc4e72866f75aeadbaed1a65c9"}
> curl http://localhost:5984/msdtest/fcd6d8fca421023581a608758a0abe35
> {"_id":"fcd6d8fca421023581a608758a0abe35","_rev":"1-fce9e6cc4e72866f75aeadbaed1a65c9","num":123456789123456789}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1830) IO timeout not configurable
[ https://issues.apache.org/jira/browse/COUCHDB-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689272#comment-13689272 ] Adam Kocoloski commented on COUCHDB-1830: - Thanks for this report. It looks like the timeout happens on a call to couch_index_updater:run/2. Perusing that gen_server implementation I don't see much at all that would cause the server to take 5 seconds to respond -- almost everything is async. Curious. > IO timeout not configurable > --- > > Key: COUCHDB-1830 > URL: https://issues.apache.org/jira/browse/COUCHDB-1830 > Project: CouchDB > Issue Type: Bug > Components: JavaScript View Server >Affects Versions: 1.3 >Reporter: Stefan Kögl >Priority: Minor > Labels: timeout > > I occasionally encounter the timeout shown in the log at > https://gist.github.com/stefankoegl/5772860. > According to [~janl] in #couchdb this is a generic gen_Server timeout (5s) > and currently not configurable. As this might not be enough in some > circumstances, there should probably be a setting for this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Fauxton Tidings
Glad to hear you guys like the new look! To clarify, Fauxton is already in master. Also, the way the deploy is setup, Fauxton gets installed alongside Futon and is hosted out of /_utils/fauxton/index.html, so we can include it at any time as an experimental feature. That said, we're actually getting quite close to feature parity with Futon, and really, with active tasks and replicator support coming along, we're just about in parity with Futon, missing a few smaller things like compaction/view_cleanup and verify installation. That said, I would like to go it locked down a bit more and have people do some solid QA on it before we replace Futon entirely. -Russell On Thu, Jun 20, 2013 at 5:49 AM, Dirkjan Ochtman wrote: > On Wed, Jun 19, 2013 at 9:38 PM, Russell Branca > wrote: > > Looks like I tried to get too fancy with embedding dropbox images. Here's > > public urls viewable on dropbox.com: > > > > all dbs: https://www.dropbox.com/s/0plfvfcwtaod0sz/Fauxton_all_dbs.png > > > > all docs and views: > > https://www.dropbox.com/s/7aws0xmw4pdkrck/Fauxton_all_docs.png > > > > view editor: > > > https://www.dropbox.com/s/ob7z9glbuopifo1/Fauxton_index_view_adv_options.png > > > > code editor: > > https://www.dropbox.com/s/trc7150otb27xbb/Fauxton_code_editor.png > > Looking pretty awesome! > > Like Filippo, I'm curious to hear if you have an approximate ETA for > landing this on master. > > Cheers, > > Dirkjan >
[jira] [Closed] (COUCHDB-284) Couchdb can't find main.js when running under a path that contains a directory name starting with two or more dashes
[ https://issues.apache.org/jira/browse/COUCHDB-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin closed COUCHDB-284. Resolution: Cannot Reproduce Couldn't reproduce on 1.2.2 release (Windows) and master(Gentoo Linux). Suddenly, I have no Ubuntu to check it there, but pretty sure that it was eventually fixed much likely in [b09c269|https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commit;h=b09c2694b36e6f91d19e9501ad3d2904c537a2b3]. Please reopen if it still actual. > Couchdb can't find main.js when running under a path that contains a > directory name starting with two or more dashes > > > Key: COUCHDB-284 > URL: https://issues.apache.org/jira/browse/COUCHDB-284 > Project: CouchDB > Issue Type: Bug > Components: Build System, Infrastructure >Affects Versions: 0.9 > Environment: Ubuntu Linux >Reporter: eric casteleijn >Priority: Minor > > When coucdb runs in directory below any directory whose name starts with two > or more dashes, say > /some/path/---foo/couch > It will error when it tries to call main.js with: > "could not open script file /path/some/-foo/couch/share/server/main.js" > Note that the first two dashes have been dropped. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-519) Continous Integration links on website
[ https://issues.apache.org/jira/browse/COUCHDB-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689345#comment-13689345 ] Jan Lehnardt commented on COUCHDB-519: -- there is http://wiki.apache.org/couchdb/CI but things aren’t very solid yet, I’ll make it more prominent once we get there. > Continous Integration links on website > -- > > Key: COUCHDB-519 > URL: https://issues.apache.org/jira/browse/COUCHDB-519 > Project: CouchDB > Issue Type: Improvement > Components: Documentation >Reporter: Paul Joseph Davis >Assignee: Paul Joseph Davis > > Add links to the buildbot CI to the website. > Links of interest: > http://ci.apache.org/waterfall?show_events=false&branch=&builder=couchdb-trunk&builder=couchdb-coverage&reload=60 > http://ci.apache.org/waterfall/help > http://ci.apache.org/projects/couchdb/cover/index.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Fauxton Tidings
On Thu, Jun 20, 2013 at 8:00 AM, Russell Branca wrote: > Glad to hear you guys like the new look! > > > To clarify, Fauxton is already in master. Also, the way the deploy is > setup, Fauxton gets installed alongside Futon and is hosted out of > /_utils/fauxton/index.html, so we can include it at any time as an > experimental feature. That said, we're actually getting quite close to > feature parity with Futon, and really, with active tasks and replicator > support coming along, we're just about in parity with Futon, missing a few > smaller things like compaction/view_cleanup and verify installation. That > said, I would like to go it locked down a bit more and have people do some > solid QA on it before we replace Futon entirely. > This is great! I also like the new look. I think we should ship this as an addition to Futon in a release ASAP!
Re: Fauxton Tidings
On Jun 20, 2013, at 18:16 , Randall Leeds wrote: > On Thu, Jun 20, 2013 at 8:00 AM, Russell Branca wrote: >> Glad to hear you guys like the new look! >> >> >> To clarify, Fauxton is already in master. Also, the way the deploy is >> setup, Fauxton gets installed alongside Futon and is hosted out of >> /_utils/fauxton/index.html, so we can include it at any time as an >> experimental feature. That said, we're actually getting quite close to >> feature parity with Futon, and really, with active tasks and replicator >> support coming along, we're just about in parity with Futon, missing a few >> smaller things like compaction/view_cleanup and verify installation. That >> said, I would like to go it locked down a bit more and have people do some >> solid QA on it before we replace Futon entirely. >> > > This is great! I also like the new look. > > I think we should ship this as an addition to Futon in a release ASAP! +1
[jira] [Commented] (COUCHDB-1824) Official documentation of replication algorithm?
[ https://issues.apache.org/jira/browse/COUCHDB-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689440#comment-13689440 ] Jens Alfke commented on COUCHDB-1824: - BTW, this is not at all an "internal detail", it's important for interoperability. Knowing how the replication protocol/algorithm works is crucial for any 3rd party software (like PouchDB / TouchDB / Couchbase Lite) that wants to be able to replicate with CouchDB. > Official documentation of replication algorithm? > > > Key: COUCHDB-1824 > URL: https://issues.apache.org/jira/browse/COUCHDB-1824 > Project: CouchDB > Issue Type: Documentation > Components: Documentation >Reporter: Nathan Vander Wilt > > Though it's in some ways an internal detail, it might be nice to provide a > canonical description of CouchDB's replication protocol (algorithm, really) > in the documentation. See links at: > http://wiki.apache.org/couchdb/Replication#Protocol_Documentation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
State of Debian Packaging
I saw that my packaging efforts came up in the IRC meeting yesterday and I wasn't there to report. Here's what's done: - Imported the most up-to-date .dsc from unstable using git-buildpackage tools - Imported the rc.2 release tarball that passed vote - Updated to use the virtual libcurl-dev, so it should work with the gnutls or openssl version - Split the packaging into couchdb and couchdb-bin as Ubuntu did downstream - Dropped patches now included upstream - Published to github at https://github.com/tilgovi/pkg-couchdb You can try it by installing git-buildpackage, cloning the pkg-couchdb repository, using git-dch to create a new debian/changelog entry for 1.3.1, and running git-buildpackage. Here's what remaining to be done, based on my notes from previous conversations with Laszlo and others: - Use system libyajl-dev - Use system libspeedy-dev - Use system libjs-json - Use system libjs-coffeescript - Publish to dist.apache.org The first 4 are Debian policy issues. As far as I'm concerned, it's not critical to fix this before we publish a .deb on the Apache mirrors. Doing this work ourselves would mean that Laszlo doesn't have to and we'd have Debian packaging in a repo that's ready for the official repo distribution. For the last, please advise what the best practice is. Is there an official place within our project that we're currently storing the windows and mac binary packaging or are you all doing that outside the ASF and just uploading the result? I opened these as issues on the github repo I set up. Laszlo: If you already have a repo for this work anywhere that you would prefer I use I would be glad to collaborate there.
[jira] [Commented] (COUCHDB-1824) Official documentation of replication algorithm?
[ https://issues.apache.org/jira/browse/COUCHDB-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689464#comment-13689464 ] Benoit Chesneau commented on COUCHDB-1824: -- [~snej] so? > Official documentation of replication algorithm? > > > Key: COUCHDB-1824 > URL: https://issues.apache.org/jira/browse/COUCHDB-1824 > Project: CouchDB > Issue Type: Documentation > Components: Documentation >Reporter: Nathan Vander Wilt > > Though it's in some ways an internal detail, it might be nice to provide a > canonical description of CouchDB's replication protocol (algorithm, really) > in the documentation. See links at: > http://wiki.apache.org/couchdb/Replication#Protocol_Documentation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1824) Official documentation of replication algorithm?
[ https://issues.apache.org/jira/browse/COUCHDB-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689497#comment-13689497 ] Jens Alfke commented on COUCHDB-1824: - I'm just pointing out that this is more significant than the original description implies. > Official documentation of replication algorithm? > > > Key: COUCHDB-1824 > URL: https://issues.apache.org/jira/browse/COUCHDB-1824 > Project: CouchDB > Issue Type: Documentation > Components: Documentation >Reporter: Nathan Vander Wilt > > Though it's in some ways an internal detail, it might be nice to provide a > canonical description of CouchDB's replication protocol (algorithm, really) > in the documentation. See links at: > http://wiki.apache.org/couchdb/Replication#Protocol_Documentation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Fauxton Tidings
On Thu, Jun 20, 2013 at 6:16 PM, Randall Leeds wrote: > I think we should ship this as an addition to Futon in a release ASAP! +1 for shipping in 1.4.0 alongside Futon! Cheers, Dirkjan
[jira] [Closed] (COUCHDB-315) Add Red Hat specific installation instructions in the README
[ https://issues.apache.org/jira/browse/COUCHDB-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shorin closed COUCHDB-315. Resolution: Duplicate It was recently fixed by the other issue. > Add Red Hat specific installation instructions in the README > > > Key: COUCHDB-315 > URL: https://issues.apache.org/jira/browse/COUCHDB-315 > Project: CouchDB > Issue Type: Improvement > Components: Documentation >Affects Versions: 0.9 > Environment: Red Hat Enterprise Linux 5 >Reporter: Nils Breunese >Priority: Minor > Attachments: README.patch > > > Currently the README file for CouchDB has specific instructions for > Debian-based (inc. Ubuntu) and Mac OS X systems. I had to adapt these > instructions in order to be able to install CouchDB on Red Hat Enterprise > Linux 5. I have attached a patch against the README file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: R16B01 + Homebrew, Archlinux etc
On 20 June 2013 12:32, Dirkjan Ochtman wrote: > On Thu, Jun 20, 2013 at 12:12 PM, Dave Cottlehuber wrote: >> 1. a special 1.4.0 release that only support R15B+ is 1.3.1 + the >> changes that are only on master at the moment ( >> 1696-update-mochiweb-2-4-2 branch). > > "Special" releases sounds... not good. Ditto, while it would be a proper release, it seems like it would be confusing for people. But a 1.3.1 + the R16B part would be a reasonable path towards a future 1.5 off master, which already has the >= R14B4 restriction. >> 2. providing homebrew with a .patch file that sits on top of 1.3.1 >> release, using a backport approach like macports does >> (1696-backport-mochiweb-2-4-2-1.3.x branch). > > That sure seems like a fine approach. This is currently my preference. >> 3. a stable 1.3.1+R16B-backport fork for homebrew with the same fix as >> #2.. I would be ok to maintain that until the next master-based >> release if required. >> (1696-backport-mochiweb-2-4-2-1.3.x branch again). This would be fine >> for homebrew team I think. > > I don't see how this is very different from #2. It's on a fork rather than a huge patch, easier to maintain and possibly more credible. >> Note that the 2.4.2 mochiweb is the *last* release that still supports >> < R15B, and it's already at 2.6.0. > > So can we do 2.6.0 mochiweb for 1.4.0? Not without ditching < R15B support, which I feel is a step too far for most distros. A+ Dave
Re: Fauxton Tidings
On Thu, Jun 20, 2013 at 1:06 PM, Dirkjan Ochtman wrote: > On Thu, Jun 20, 2013 at 6:16 PM, Randall Leeds > wrote: > > I think we should ship this as an addition to Futon in a release ASAP! > > +1 for shipping in 1.4.0 alongside Futon! > > Cheers, > > Dirkjan > Sounds good! -Russell
Re: R16B01 + Homebrew, Archlinux etc
On Thu, Jun 20, 2013 at 10:18 PM, Dave Cottlehuber wrote: >>> 3. a stable 1.3.1+R16B-backport fork for homebrew with the same fix as >>> #2.. I would be ok to maintain that until the next master-based >>> release if required. >>> (1696-backport-mochiweb-2-4-2-1.3.x branch again). This would be fine >>> for homebrew team I think. >> >> I don't see how this is very different from #2. > > It's on a fork rather than a huge patch, easier to maintain and > possibly more credible. We... we can keep the branch around for our maintenance, but it seems to me like most distros would prefer tarball + patch over some Git branch. At least that's the way we do it on Gentoo. >>> Note that the 2.4.2 mochiweb is the *last* release that still supports >>> < R15B, and it's already at 2.6.0. >> >> So can we do 2.6.0 mochiweb for 1.4.0? > > Not without ditching < R15B support, which I feel is a step too far > for most distros. Ugh. Well, I'd say people who want newer CouchDB can get newer Erlang. If you can build Couch from scratch, why not do Erlang too? I'm firmly of the opinion that, if you're on some rock-stable distro, you get your rock-stable CouchDB. If you want the fresh-faced fun CouchDB, you can take care of your own fresh-faced intermediate dependencies as well. But then I might be biased by my nicely source-based distro thing. Cheers, Dirkjan
Re: State of Debian Packaging
On 20 June 2013 19:53, Randall Leeds wrote: > I saw that my packaging efforts came up in the IRC meeting yesterday > and I wasn't there to report. > > Here's what's done: > - Imported the most up-to-date .dsc from unstable using git-buildpackage > tools > - Imported the rc.2 release tarball that passed vote > - Updated to use the virtual libcurl-dev, so it should work with the > gnutls or openssl version > - Split the packaging into couchdb and couchdb-bin as Ubuntu did downstream > - Dropped patches now included upstream > - Published to github at https://github.com/tilgovi/pkg-couchdb > > You can try it by installing git-buildpackage, cloning the pkg-couchdb > repository, using git-dch to create a new debian/changelog entry for > 1.3.1, and running git-buildpackage. > > Here's what remaining to be done, based on my notes from previous > conversations with Laszlo and others: > - Use system libyajl-dev > - Use system libspeedy-dev > - Use system libjs-json > - Use system libjs-coffeescript > - Publish to dist.apache.org > > The first 4 are Debian policy issues. As far as I'm concerned, it's > not critical to fix this before we publish a .deb on the Apache > mirrors. Doing this work ourselves would mean that Laszlo doesn't have > to and we'd have Debian packaging in a repo that's ready for the > official repo distribution. > > For the last, please advise what the best practice is. Is there an > official place within our project that we're currently storing the > windows and mac binary packaging or are you all doing that outside the > ASF and just uploading the result? I'd like to merge my windows build scripts into couchdb proper (I will open a JIRA for that), and during the release process, we currently stash binaries / packages into svn https://dist.apache.org/repos/dist/dev/couchdb/binary/ > I opened these as issues on the github repo I set up. > > Laszlo: If you already have a repo for this work anywhere that you > would prefer I use I would be glad to collaborate there.
Re: State of Debian Packaging
On Thu, Jun 20, 2013 at 2:02 PM, Dave Cottlehuber wrote: > > I'd like to merge my windows build scripts into couchdb proper (I will > open a JIRA for that), and during the release process, we currently > stash binaries / packages into svn > https://dist.apache.org/repos/dist/dev/couchdb/binary/ In the case of the Debian packaging, I'd like to not have it in the main source tree, since that creates pain if downstream packagers decide to diverge from our way of doing it. But perhaps we (can) have a separate place for all this packaging stuff?
couchdb pull request: couch_users_db: introduce public_users option
GitHub user indutny opened a pull request: https://github.com/apache/couchdb/pull/67 couch_users_db: introduce public_users option When `couchdb.public_users` is set to `true`, getting `/_users/id` will return user document with sensitive information stripped. You can merge this pull request into a Git repository by running: $ git pull https://github.com/indutny/couchdb feature/public_users Alternatively you can review and apply these changes as the patch at: https://github.com/apache/couchdb/pull/67.patch
Re: git commit: updated refs/heads/master to 9cf9b53
On Fri, Jun 21, 2013 at 1:46 AM, wrote: > +chmod 0755 /usr/local/etc/couchdb Is this reasonable change? Config files may contains some sensitive data like secret token for proxy_auth, oauth credentials, server admins names etc. which probably shouldn't be shared with anyone regular OS user (unless his is in couchdb group). -- ,,,^..^,,, On Fri, Jun 21, 2013 at 1:46 AM, wrote: > Updated Branches: > refs/heads/master cbbd7d56b -> 9cf9b53d2 > > > fix perms on install instructions > > > Project: http://git-wip-us.apache.org/repos/asf/couchdb/repo > Commit: http://git-wip-us.apache.org/repos/asf/couchdb/commit/9cf9b53d > Tree: http://git-wip-us.apache.org/repos/asf/couchdb/tree/9cf9b53d > Diff: http://git-wip-us.apache.org/repos/asf/couchdb/diff/9cf9b53d > > Branch: refs/heads/master > Commit: 9cf9b53d2cee9976a5b215af52672838abec0d6b > Parents: cbbd7d5 > Author: Jan Lehnardt > Authored: Thu Jun 20 23:46:31 2013 +0200 > Committer: Jan Lehnardt > Committed: Thu Jun 20 23:46:31 2013 +0200 > > -- > INSTALL.Unix | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > -- > > > http://git-wip-us.apache.org/repos/asf/couchdb/blob/9cf9b53d/INSTALL.Unix > -- > diff --git a/INSTALL.Unix b/INSTALL.Unix > index 854fd13..76ba8eb 100644 > --- a/INSTALL.Unix > +++ b/INSTALL.Unix > @@ -230,10 +230,10 @@ Change the ownership of the CouchDB directories by > running: > > Change the permission of the CouchDB directories by running: > > -chmod 0770 /usr/local/etc/couchdb > -chmod 0770 /usr/local/var/lib/couchdb > -chmod 0770 /usr/local/var/log/couchdb > -chmod 0770 /usr/local/var/run/couchdb > +chmod 0755 /usr/local/etc/couchdb > +chmod 0755 /usr/local/var/lib/couchdb > +chmod 0755 /usr/local/var/log/couchdb > +chmod 0755 /usr/local/var/run/couchdb > > Running as a Daemon > --- >
Re: git commit: updated refs/heads/master to 9cf9b53
On Jun 20, 2013, at 23:52 , Alexander Shorin wrote: > On Fri, Jun 21, 2013 at 1:46 AM, wrote: >> +chmod 0755 /usr/local/etc/couchdb > > Is this reasonable change? Config files may contains some sensitive > data like secret token for proxy_auth, oauth credentials, server > admins names etc. which probably shouldn't be shared with anyone > regular OS user (unless his is in couchdb group). Ah, good point, that was probably the reasoning there. I’ll revert. Jan -- > -- > ,,,^..^,,, > > > On Fri, Jun 21, 2013 at 1:46 AM, wrote: >> Updated Branches: >> refs/heads/master cbbd7d56b -> 9cf9b53d2 >> >> >> fix perms on install instructions >> >> >> Project: http://git-wip-us.apache.org/repos/asf/couchdb/repo >> Commit: http://git-wip-us.apache.org/repos/asf/couchdb/commit/9cf9b53d >> Tree: http://git-wip-us.apache.org/repos/asf/couchdb/tree/9cf9b53d >> Diff: http://git-wip-us.apache.org/repos/asf/couchdb/diff/9cf9b53d >> >> Branch: refs/heads/master >> Commit: 9cf9b53d2cee9976a5b215af52672838abec0d6b >> Parents: cbbd7d5 >> Author: Jan Lehnardt >> Authored: Thu Jun 20 23:46:31 2013 +0200 >> Committer: Jan Lehnardt >> Committed: Thu Jun 20 23:46:31 2013 +0200 >> >> -- >> INSTALL.Unix | 8 >> 1 file changed, 4 insertions(+), 4 deletions(-) >> -- >> >> >> http://git-wip-us.apache.org/repos/asf/couchdb/blob/9cf9b53d/INSTALL.Unix >> -- >> diff --git a/INSTALL.Unix b/INSTALL.Unix >> index 854fd13..76ba8eb 100644 >> --- a/INSTALL.Unix >> +++ b/INSTALL.Unix >> @@ -230,10 +230,10 @@ Change the ownership of the CouchDB directories by >> running: >> >> Change the permission of the CouchDB directories by running: >> >> -chmod 0770 /usr/local/etc/couchdb >> -chmod 0770 /usr/local/var/lib/couchdb >> -chmod 0770 /usr/local/var/log/couchdb >> -chmod 0770 /usr/local/var/run/couchdb >> +chmod 0755 /usr/local/etc/couchdb >> +chmod 0755 /usr/local/var/lib/couchdb >> +chmod 0755 /usr/local/var/log/couchdb >> +chmod 0755 /usr/local/var/run/couchdb >> >> Running as a Daemon >> --- >>
