[jira] [Commented] (COUCHDB-1416) the requested_path that is passed to a show is wrong on a vhost with a path
[ https://issues.apache.org/jira/browse/COUCHDB-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1321#comment-1321 ] Benoit Chesneau commented on COUCHDB-1416: -- It is isn't possible to use the test suite to tests vhists. Since the vhost is depending on the Host header. It's unlikely that you can change it in your ajax request. I'm surprised you can't get this path since we are using it for the oauth check. Can't you use the header `x-couchdb-vhost-path` ? Anyway, the full problem right now, is that we don't pass any record while rewriting the uri. I can see 2 solutions in near future: 1. Keeping a state and sendint oit back when the mochiweb request have been modified 2. Keeping this state in the registry which was already proposed when we have to manage this step. I will have a look on it this week. the requested_path that is passed to a show is wrong on a vhost with a path Key: COUCHDB-1416 URL: https://issues.apache.org/jira/browse/COUCHDB-1416 Project: CouchDB Issue Type: Bug Components: HTTP Interface Affects Versions: 1.2 Reporter: Ryan Ramage Priority: Minor In a show or list, it is impossible to construct a full url that an end user could use to re-request the resource, given the various combinations of vhosts and rewrites. The major one is if the vhost contains a path component, this path information is not passed to the show at all. I have created three tests that highlight the condition, currently failing for one test, with the two passing to prevent regressions. The commit can be found here: https://github.com/ryanramage/couchdb/commit/e9417480e2ce160f359d9508dcec3d4e56045a60 I have talked this over with JasonSmith and bennoitc on #couchdb and they asked me to write the tests and raise the jira. -- 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-1416) the requested_path that is passed to a show is wrong on a vhost with a path
[ https://issues.apache.org/jira/browse/COUCHDB-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214449#comment-13214449 ] Jason Smith commented on COUCHDB-1416: -- x-couchdb-vhost-path does not include the VPath part, i.e. the path part from the vhost definition. [vhosts] example.com/some_path = /some_db After vhost processing, /some_path is lost forever. the requested_path that is passed to a show is wrong on a vhost with a path Key: COUCHDB-1416 URL: https://issues.apache.org/jira/browse/COUCHDB-1416 Project: CouchDB Issue Type: Bug Components: HTTP Interface Affects Versions: 1.2 Reporter: Ryan Ramage Priority: Minor In a show or list, it is impossible to construct a full url that an end user could use to re-request the resource, given the various combinations of vhosts and rewrites. The major one is if the vhost contains a path component, this path information is not passed to the show at all. I have created three tests that highlight the condition, currently failing for one test, with the two passing to prevent regressions. The commit can be found here: https://github.com/ryanramage/couchdb/commit/e9417480e2ce160f359d9508dcec3d4e56045a60 I have talked this over with JasonSmith and bennoitc on #couchdb and they asked me to write the tests and raise the jira. -- 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] [Updated] (COUCHDB-1416) the requested_path that is passed to a show is wrong on a vhost with a path
[ https://issues.apache.org/jira/browse/COUCHDB-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Smith updated COUCHDB-1416: - Attachment: A_0004-For-a-vhost-correctly-reflect-true-requested-path.patch A_0003-Store-the-entire-requested-path-in-x-couchdb-vhost-f.patch A_0002-Compatibility-with-the-CLI-test-runner.patch A_0001-Testing-requested_path-for-various-combinations-of-r.patch First crack at fixing this bug. This series passes Ryan's tests and does not seem to harm the other JS or etap tests. (I was concerned about oauth but it passed.) My branch for this: https://github.com/jhs/couchdb/tree/COUCHDB-1416 It is based from Ryan's tests, and thus it is based on the 1.2.x branch for now. the requested_path that is passed to a show is wrong on a vhost with a path Key: COUCHDB-1416 URL: https://issues.apache.org/jira/browse/COUCHDB-1416 Project: CouchDB Issue Type: Bug Components: HTTP Interface Affects Versions: 1.2 Reporter: Ryan Ramage Priority: Minor Attachments: A_0001-Testing-requested_path-for-various-combinations-of-r.patch, A_0002-Compatibility-with-the-CLI-test-runner.patch, A_0003-Store-the-entire-requested-path-in-x-couchdb-vhost-f.patch, A_0004-For-a-vhost-correctly-reflect-true-requested-path.patch In a show or list, it is impossible to construct a full url that an end user could use to re-request the resource, given the various combinations of vhosts and rewrites. The major one is if the vhost contains a path component, this path information is not passed to the show at all. I have created three tests that highlight the condition, currently failing for one test, with the two passing to prevent regressions. The commit can be found here: https://github.com/ryanramage/couchdb/commit/e9417480e2ce160f359d9508dcec3d4e56045a60 I have talked this over with JasonSmith and bennoitc on #couchdb and they asked me to write the tests and raise the jira. -- 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] [Closed] (COUCHDB-1416) the requested_path that is passed to a show is wrong on a vhost with a path
[ https://issues.apache.org/jira/browse/COUCHDB-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Lehnardt closed COUCHDB-1416. - Resolution: Not A Problem A vhost key should never include a path. It is strictly for matching the Host: example.com header which is defined by RFC 2616 as the Internet host and port number of the resource being requested — http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23 the requested_path that is passed to a show is wrong on a vhost with a path Key: COUCHDB-1416 URL: https://issues.apache.org/jira/browse/COUCHDB-1416 Project: CouchDB Issue Type: Bug Components: HTTP Interface Affects Versions: 1.2 Reporter: Ryan Ramage Priority: Minor Attachments: A_0001-Testing-requested_path-for-various-combinations-of-r.patch, A_0002-Compatibility-with-the-CLI-test-runner.patch, A_0003-Store-the-entire-requested-path-in-x-couchdb-vhost-f.patch, A_0004-For-a-vhost-correctly-reflect-true-requested-path.patch In a show or list, it is impossible to construct a full url that an end user could use to re-request the resource, given the various combinations of vhosts and rewrites. The major one is if the vhost contains a path component, this path information is not passed to the show at all. I have created three tests that highlight the condition, currently failing for one test, with the two passing to prevent regressions. The commit can be found here: https://github.com/ryanramage/couchdb/commit/e9417480e2ce160f359d9508dcec3d4e56045a60 I have talked this over with JasonSmith and bennoitc on #couchdb and they asked me to write the tests and raise the jira. -- 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: [VOTE] Apache CouchDB 1.2.0 release, second round
+1 md5, sha, sig verified. make check passes. futon fully passes in FF 10.0. fully passes in Chrome 17 (except attachment_ranges). OS X 10.7.3, spidermonkey 1.8.5, icu 4.8.1.1. B. On 23 February 2012 04:39, Brian Mitchell binar...@gmail.com wrote: Same result as last vote on OS X 10.7.3 using Erlang OTP R15B and spidermonkey 1.8.5 . `make check` hangs on 076-file-compression.t and passes in the browser as long as I'm in private browsing mode or have the cache disabled. I'll do a test on Linux tomorrow with R14B04 before I +1. Brian. On Wednesday, February 22, 2012 at 18:28 , Noah Slater wrote: Hello, I would like call a vote for the Apache CouchDB 1.2.0 release, second round. We encourage the whole community to download and test these release artifacts so that any critical issues can be resolved before the release is made. Everyone is free to vote on this release, so get stuck in! We are voting on the following release artifacts: http://people.apache.org/~nslater/dist/1.2.0/ These artifacts have been built from the following tree-ish in Git: 4cd60f3d1683a3445c3248f48ae064fb573db2a1 Please follow the test procedure before voting: http://wiki.apache.org/couchdb/Test_procedure Thank you. Happy voting, N
Re: [VOTE] Apache CouchDB 1.2.0 release, second round
omitted to say this was R14B04, sorry. On 23 February 2012 11:33, Robert Newson rnew...@apache.org wrote: +1 md5, sha, sig verified. make check passes. futon fully passes in FF 10.0. fully passes in Chrome 17 (except attachment_ranges). OS X 10.7.3, spidermonkey 1.8.5, icu 4.8.1.1. B. On 23 February 2012 04:39, Brian Mitchell binar...@gmail.com wrote: Same result as last vote on OS X 10.7.3 using Erlang OTP R15B and spidermonkey 1.8.5 . `make check` hangs on 076-file-compression.t and passes in the browser as long as I'm in private browsing mode or have the cache disabled. I'll do a test on Linux tomorrow with R14B04 before I +1. Brian. On Wednesday, February 22, 2012 at 18:28 , Noah Slater wrote: Hello, I would like call a vote for the Apache CouchDB 1.2.0 release, second round. We encourage the whole community to download and test these release artifacts so that any critical issues can be resolved before the release is made. Everyone is free to vote on this release, so get stuck in! We are voting on the following release artifacts: http://people.apache.org/~nslater/dist/1.2.0/ These artifacts have been built from the following tree-ish in Git: 4cd60f3d1683a3445c3248f48ae064fb573db2a1 Please follow the test procedure before voting: http://wiki.apache.org/couchdb/Test_procedure Thank you. Happy voting, N
Re: [VOTE] Apache CouchDB 1.2.0 release, second round
On Thu, Feb 23, 2012 at 3:51 AM, Paul Davis paul.joseph.da...@gmail.com wrote: More than likely this is the SSL issue that Erlang has had issues with. Perhaps its time that I go in and see if I can't patch Erlang to use the newer OS X functions. Filipe had more details but IIRC the fix was basically to compile your own SSL and get Erlang to link against that. Yes smth like: https://github.com/refuge/refuge/wiki/Refuge-Build-on-MacOSX-Lion - benoît
[jira] [Commented] (COUCHDB-1416) the requested_path that is passed to a show is wrong on a vhost with a path
[
https://issues.apache.org/jira/browse/COUCHDB-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214568#comment-13214568
]
Jason Smith commented on COUCHDB-1416:
--
Ryan, I believe there is still a bug here, triggered with just a vhost/rewrite
combo. Would it be possible for you to modify the test to strictly use
hostnames with no paths as the vhost key?
Jan, two things:
1. Your description is counter to the actual CouchDB code. Paths are valid
vhost keys. example.com/foo and example.com/bar are distinct vhosts in 1.2.x.
2. In any case, the bug in this ticket is that the path a browser sends to
couch is somehow forgotten by the time it hits a _show function as
req.requested_path. Ryan might fill in the details but AFAIK, this will fail.
[vhosts]
example.com = /db/_design/ddoc/_rewrite
_rewrites: [{from:show, to:_show/show_doc}]
function(doc, req) {
// show_doc
return JSON.stringify(req.requested_path)
}
GET /foo
Host: example.com
The response should be /foo but it is not.
the requested_path that is passed to a show is wrong on a vhost with a path
Key: COUCHDB-1416
URL: https://issues.apache.org/jira/browse/COUCHDB-1416
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 1.2
Reporter: Ryan Ramage
Priority: Minor
Attachments:
A_0001-Testing-requested_path-for-various-combinations-of-r.patch,
A_0002-Compatibility-with-the-CLI-test-runner.patch,
A_0003-Store-the-entire-requested-path-in-x-couchdb-vhost-f.patch,
A_0004-For-a-vhost-correctly-reflect-true-requested-path.patch
In a show or list, it is impossible to construct a full url that an end user
could use to re-request the resource, given the various combinations of
vhosts and rewrites.
The major one is if the vhost contains a path component, this path
information is not passed to the show at all.
I have created three tests that highlight the condition, currently failing
for one test, with the two passing to prevent regressions.
The commit can be found here:
https://github.com/ryanramage/couchdb/commit/e9417480e2ce160f359d9508dcec3d4e56045a60
I have talked this over with JasonSmith and bennoitc on #couchdb and they
asked me to write the tests and raise the jira.
--
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-1416) the requested_path that is passed to a show is wrong on a vhost with a path
[ https://issues.apache.org/jira/browse/COUCHDB-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214569#comment-13214569 ] Jason Smith commented on COUCHDB-1416: -- Forgot to mention, also the port is not involved in vhost lookups. That changed between 1.1 and 1.2. the requested_path that is passed to a show is wrong on a vhost with a path Key: COUCHDB-1416 URL: https://issues.apache.org/jira/browse/COUCHDB-1416 Project: CouchDB Issue Type: Bug Components: HTTP Interface Affects Versions: 1.2 Reporter: Ryan Ramage Priority: Minor Attachments: A_0001-Testing-requested_path-for-various-combinations-of-r.patch, A_0002-Compatibility-with-the-CLI-test-runner.patch, A_0003-Store-the-entire-requested-path-in-x-couchdb-vhost-f.patch, A_0004-For-a-vhost-correctly-reflect-true-requested-path.patch In a show or list, it is impossible to construct a full url that an end user could use to re-request the resource, given the various combinations of vhosts and rewrites. The major one is if the vhost contains a path component, this path information is not passed to the show at all. I have created three tests that highlight the condition, currently failing for one test, with the two passing to prevent regressions. The commit can be found here: https://github.com/ryanramage/couchdb/commit/e9417480e2ce160f359d9508dcec3d4e56045a60 I have talked this over with JasonSmith and bennoitc on #couchdb and they asked me to write the tests and raise the jira. -- 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: [VOTE] Apache CouchDB 1.2.0 release, second round
Bob, When I was suffering this, I would get bus errors or segmentation faults at random. They are non-deterministic, as far as I can tell. As I said at the start of this thread, I got a segfault on my first run through, and not my second or third. On Thu, Feb 23, 2012 at 3:06 AM, Bob Dionne dio...@dionne-associates.comwrote: perhaps, oddly if I try it without running make distcheck first I get a different error: Segmentation fault: 11 dependencies are fun On Feb 22, 2012, at 9:51 PM, Paul Davis wrote: More than likely this is the SSL issue that Erlang has had issues with. Perhaps its time that I go in and see if I can't patch Erlang to use the newer OS X functions. Filipe had more details but IIRC the fix was basically to compile your own SSL and get Erlang to link against that. On Wed, Feb 22, 2012 at 8:07 PM, Bob Dionne dio...@dionne-associates.com wrote: I've been doing that all along, master branch, 1.0.x, any source build is fine. I saw these occasionally before on the Mackbook Pro, this is the first one I've seen on the MBA It is odd that I'm only seeing it on this build, the only diff being I hardly ever run make distcheck. I'll try it without running that. On Feb 22, 2012, at 8:02 PM, Noah Slater wrote: Could you try again a few times maybe, try testing the source directly from your checkout? On Thu, Feb 23, 2012 at 12:26 AM, Bob Dionne dio...@dionne-associates.comwrote: I've seen this page before Noah, and something like these Bus errors. I think it might be the use of R15B What's odd is that I don't have any problems withe the 1.2 branch, or any branch for that matter On Feb 22, 2012, at 6:55 PM, Noah Slater wrote: Can you try this and report back please: http://wiki.apache.org/couchdb/Troubleshooting#Segmentation_faults_and_bus_errors On Wed, Feb 22, 2012 at 11:51 PM, Bob Dionne dio...@dionne-associates.comwrote: make distcheck ran ok server keeps crashing with: Bus error: 10 On Feb 22, 2012, at 6:29 PM, Noah Slater wrote: I might add that I got a segfault on the first try with the test suite, but was unable to reproduce it with two further runs. I would appreciate some feedback on this to assure me that it's nothing to worry about.
[jira] [Commented] (COUCHDB-1415) Re-insering a document silently fails after compact is executed
[
https://issues.apache.org/jira/browse/COUCHDB-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214679#comment-13214679
]
James Howe commented on COUCHDB-1415:
-
Does this only happen when step 5 is a POST, or are PUTs affected too?
Re-insering a document silently fails after compact is executed
---
Key: COUCHDB-1415
URL: https://issues.apache.org/jira/browse/COUCHDB-1415
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 1.1.1
Environment: Tested on multiple linux platforms
Reporter: Viktor Szabo
Fix For: 1.3
When a document is re-inserted after a compact operation using the same
contents it was originally created, the insert operation is silently ignored,
leaving the client unaware of the fact it's document is not available in the
database.
Can be reproduced using the following sequence of steps:
alias curl='curl -H Content-Type: application/json'
url=http://localhost:5984/database;
1 curl -X PUT $url
2 curl -X POST $url -d '{_id: bug, key: value}'
3 curl -X DELETE $url/bug?rev=1-59414e77c768bc202142ac82c2f129de
4 curl -X POST $url/_compact
5 curl -X POST $url -d '{_id: bug, key: value}'
6 curl -X GET $url/bug
(bug here)
1 {ok:true}
201
2 [{ok:true,id:bug,rev:1-59414e77c768bc202142ac82c2f129de}]
201
3 {ok:true,id:bug,rev:2-9b2e3bcc3752a3a952a3570b2ed4d27e}
200
4 {ok:true}
202
5 [{ok:true,id:bug,rev:1-59414e77c768bc202142ac82c2f129de}]
201
6 {error:not_found,reason:deleted}
404
CouchDB shouldn't report ok on step 5 and then go on to claim that the doc
is deleted. Also, it seems to work on second try:
7 curl -X POST $url -d '{_id: bug, key: value}'
8 curl -X GET $url/bug
7 {ok:true,id:bug,rev:3-674f864b73df1c80925e48436e21d550}
201
8 {_id:bug,_rev:3-674f864b73df1c80925e48436e21d550,key:value}
200
--
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-1418) make -j builds can cause build error with help2man
make -j builds can cause build error with help2man -- Key: COUCHDB-1418 URL: https://issues.apache.org/jira/browse/COUCHDB-1418 Project: CouchDB Issue Type: Bug Components: Build System Affects Versions: 1.1, 1.2, 1.3 Reporter: Jan Lehnardt Assignee: Noah Slater Priority: Minor make -jN enables parallel execution of build tasks. When a system has help2man installed, the build system might invoke couchjs -h to generate the help before the couchjs binary was finished building. Subsequent runs of make -jN or make without the -jN option succeed as usual. -- 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-1419) bail if g++ isn't found or use gcc for spidermonkey checks in ./configure
bail if g++ isn't found or use gcc for spidermonkey checks in ./configure - Key: COUCHDB-1419 URL: https://issues.apache.org/jira/browse/COUCHDB-1419 Project: CouchDB Issue Type: Bug Components: Build System Affects Versions: 1.1, 1.2, 1.3 Reporter: Jan Lehnardt it seems we don't bail out of ./configure if g++ isn't installed, but the ./configure checks for SpiderMonkey require g++ and report Spidermonkey not found, although it is g++ that is missing -- 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-1415) Re-insering a document silently fails after compact is executed
[
https://issues.apache.org/jira/browse/COUCHDB-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214867#comment-13214867
]
Paul Joseph Davis commented on COUCHDB-1415:
Should affect both as well as _bulk_docs. The actual issue is quite deep in the
revision merging and conflict checks.
Re-insering a document silently fails after compact is executed
---
Key: COUCHDB-1415
URL: https://issues.apache.org/jira/browse/COUCHDB-1415
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 1.1.1
Environment: Tested on multiple linux platforms
Reporter: Viktor Szabo
Fix For: 1.3
When a document is re-inserted after a compact operation using the same
contents it was originally created, the insert operation is silently ignored,
leaving the client unaware of the fact it's document is not available in the
database.
Can be reproduced using the following sequence of steps:
alias curl='curl -H Content-Type: application/json'
url=http://localhost:5984/database;
1 curl -X PUT $url
2 curl -X POST $url -d '{_id: bug, key: value}'
3 curl -X DELETE $url/bug?rev=1-59414e77c768bc202142ac82c2f129de
4 curl -X POST $url/_compact
5 curl -X POST $url -d '{_id: bug, key: value}'
6 curl -X GET $url/bug
(bug here)
1 {ok:true}
201
2 [{ok:true,id:bug,rev:1-59414e77c768bc202142ac82c2f129de}]
201
3 {ok:true,id:bug,rev:2-9b2e3bcc3752a3a952a3570b2ed4d27e}
200
4 {ok:true}
202
5 [{ok:true,id:bug,rev:1-59414e77c768bc202142ac82c2f129de}]
201
6 {error:not_found,reason:deleted}
404
CouchDB shouldn't report ok on step 5 and then go on to claim that the doc
is deleted. Also, it seems to work on second try:
7 curl -X POST $url -d '{_id: bug, key: value}'
8 curl -X GET $url/bug
7 {ok:true,id:bug,rev:3-674f864b73df1c80925e48436e21d550}
201
8 {_id:bug,_rev:3-674f864b73df1c80925e48436e21d550,key:value}
200
--
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-1420) Futon display breaks on really long db name
Futon display breaks on really long db name --- Key: COUCHDB-1420 URL: https://issues.apache.org/jira/browse/COUCHDB-1420 Project: CouchDB Issue Type: Bug Components: Futon Affects Versions: 1.2 Reporter: Sam Bisbee Priority: Minor Futon's display breaks if the database name is too long and some information is just not retrieved. Example database name: bpjwguulsnozjugktpmtnsucxlojprxyhbmuxkyuqepaptmjvwctautgpiawxiodsqkdrposfrdayauvzkgixkztdaamhhihifdvdqykpqacpmifosdouzlqwxkbooxnebxohdueppgpawfsetsayrzeigevclmnplfewskbzepwqkrpuvsqeqkdnmkgxwrsmdqmgcqkhfkgtnfmcompyugwmymaoguzxwfjn Marking minor since people who want db names this long/crazy are (a) a minority and (b) should be accepting of minor UI issues. Cheers. -- 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: [VOTE] Apache CouchDB 1.2.0 release, second round
Can someone convince me this bus error stuff and segfaults is not a blocking issue. Bob tells me that he's followed the steps above and he's still experiencing the issues. Bob, you did follow the steps to install your own SSL right? On Thu, Feb 23, 2012 at 5:09 PM, Jan Lehnardt j...@apache.org wrote: On Feb 23, 2012, at 00:28 , Noah Slater wrote: Hello, I would like call a vote for the Apache CouchDB 1.2.0 release, second round. We encourage the whole community to download and test these release artifacts so that any critical issues can be resolved before the release is made. Everyone is free to vote on this release, so get stuck in! We are voting on the following release artifacts: http://people.apache.org/~nslater/dist/1.2.0/ These artifacts have been built from the following tree-ish in Git: 4cd60f3d1683a3445c3248f48ae064fb573db2a1 Please follow the test procedure before voting: http://wiki.apache.org/couchdb/Test_procedure Thank you. Happy voting, Signature and hashes check out. Mac OS X 10.7.3, 64bit, SpiderMonkey 1.8.0, Erlang R14B04: make check works fine, browser tests in Safari work fine. Mac OS X 10.7.3, 64bit, SpiderMonkey 1.8.5, Erlang R14B04: make check works fine, browser tests in Safari work fine. FreeBSD 9.0, 64bit, SpiderMonkey 1.7.0, Erlang R14B04: make check works fine, browser tests in Safari work fine. CentOS 6.2, 64bit, SpiderMonkey 1.8.5, Erlang R14B04: make check works fine, browser tests in Firefox work fine. Ubuntu 11.4, 64bit, SpiderMonkey 1.8.5, Erlang R14B02: make check works fine, browser tests in Firefox work fine. Ubuntu 10.4, 32bit, SpiderMonkey 1.8.0, Erlang R13B03: make check fails in - 076-file-compression.t: https://gist.github.com/1893373 - 220-compaction-daemon.t: https://gist.github.com/1893387 This on runs in a VM and is 32bit, so I don't know if there's anything in the tests that rely on 64bittyness or the R14B03. Filipe, I think you worked on both features, do you have an idea? I tried running it all through Erlang R15B on Mac OS X 1.7.3, but a good way into `make check` the tests would just stop and hang. The last time, repeatedly in 160-vhosts.t, but when run alone, that test finished in under five seconds. I'm not sure what the issue is here. Despite the things above, I'm happy to give this a +1 if we put a warning about R15B on the download page. Great work all! Cheers Jan --
[jira] [Commented] (COUCHDB-1420) Futon display breaks on really long db name
[
https://issues.apache.org/jira/browse/COUCHDB-1420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13214923#comment-13214923
]
Robert Newson commented on COUCHDB-1420:
We should reject dbnames over 256 characters as the database will be stored in
a file of that name and many filesystems have a 256 char limit. {error,
etoolongfilename} is somesuch.
Futon display breaks on really long db name
---
Key: COUCHDB-1420
URL: https://issues.apache.org/jira/browse/COUCHDB-1420
Project: CouchDB
Issue Type: Bug
Components: Database Core, Futon
Affects Versions: 1.2
Reporter: Sam Bisbee
Priority: Minor
Futon's display breaks if the database name is too long and some information
is just not retrieved.
Example database name:
bpjwguulsnozjugktpmtnsucxlojprxyhbmuxkyuqepaptmjvwctautgpiawxiodsqkdrposfrdayauvzkgixkztdaamhhihifdvdqykpqacpmifosdouzlqwxkbooxnebxohdueppgpawfsetsayrzeigevclmnplfewskbzepwqkrpuvsqeqkdnmkgxwrsmdqmgcqkhfkgtnfmcompyugwmymaoguzxwfjn
Marking minor since people who want db names this long/crazy are (a) a
minority and (b) should be accepting of minor UI issues.
Cheers.
--
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] [Updated] (COUCHDB-1420) Reject databases with names longer than typical filename limit
[ https://issues.apache.org/jira/browse/COUCHDB-1420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Newson updated COUCHDB-1420: --- Component/s: Database Core Priority: Major (was: Minor) Summary: Reject databases with names longer than typical filename limit (was: Futon display breaks on really long db name) Reject databases with names longer than typical filename limit -- Key: COUCHDB-1420 URL: https://issues.apache.org/jira/browse/COUCHDB-1420 Project: CouchDB Issue Type: Bug Components: Database Core, Futon Affects Versions: 1.2 Reporter: Sam Bisbee Futon's display breaks if the database name is too long and some information is just not retrieved. Example database name: bpjwguulsnozjugktpmtnsucxlojprxyhbmuxkyuqepaptmjvwctautgpiawxiodsqkdrposfrdayauvzkgixkztdaamhhihifdvdqykpqacpmifosdouzlqwxkbooxnebxohdueppgpawfsetsayrzeigevclmnplfewskbzepwqkrpuvsqeqkdnmkgxwrsmdqmgcqkhfkgtnfmcompyugwmymaoguzxwfjn Marking minor since people who want db names this long/crazy are (a) a minority and (b) should be accepting of minor UI issues. Cheers. -- 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: [VOTE] Apache CouchDB 1.2.0 release, second round
On Thu, Feb 23, 2012 at 9:09 AM, Jan Lehnardt j...@apache.org wrote: On Feb 23, 2012, at 00:28 , Noah Slater wrote: Hello, I would like call a vote for the Apache CouchDB 1.2.0 release, second round. We encourage the whole community to download and test these release artifacts so that any critical issues can be resolved before the release is made. Everyone is free to vote on this release, so get stuck in! We are voting on the following release artifacts: http://people.apache.org/~nslater/dist/1.2.0/ These artifacts have been built from the following tree-ish in Git: 4cd60f3d1683a3445c3248f48ae064fb573db2a1 Please follow the test procedure before voting: http://wiki.apache.org/couchdb/Test_procedure Thank you. Happy voting, Signature and hashes check out. Mac OS X 10.7.3, 64bit, SpiderMonkey 1.8.0, Erlang R14B04: make check works fine, browser tests in Safari work fine. Mac OS X 10.7.3, 64bit, SpiderMonkey 1.8.5, Erlang R14B04: make check works fine, browser tests in Safari work fine. FreeBSD 9.0, 64bit, SpiderMonkey 1.7.0, Erlang R14B04: make check works fine, browser tests in Safari work fine. CentOS 6.2, 64bit, SpiderMonkey 1.8.5, Erlang R14B04: make check works fine, browser tests in Firefox work fine. Ubuntu 11.4, 64bit, SpiderMonkey 1.8.5, Erlang R14B02: make check works fine, browser tests in Firefox work fine. Ubuntu 10.4, 32bit, SpiderMonkey 1.8.0, Erlang R13B03: make check fails in - 076-file-compression.t: https://gist.github.com/1893373 - 220-compaction-daemon.t: https://gist.github.com/1893387 This on runs in a VM and is 32bit, so I don't know if there's anything in the tests that rely on 64bittyness or the R14B03. Filipe, I think you worked on both features, do you have an idea? The compression fails because snappy NIF needs R13B04+ (forgot to update the test to work with R13B03 and below). For the compaction one, on ubuntu/debian you need to install the package 'erlang-os-mon' I tried running it all through Erlang R15B on Mac OS X 1.7.3, but a good way into `make check` the tests would just stop and hang. The last time, repeatedly in 160-vhosts.t, but when run alone, that test finished in under five seconds. I'm not sure what the issue is here. Despite the things above, I'm happy to give this a +1 if we put a warning about R15B on the download page. Great work all! Cheers Jan -- -- Filipe David Manana, Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men.
[jira] [Updated] (COUCHDB-1420) Futon display breaks on really long db name
[ https://issues.apache.org/jira/browse/COUCHDB-1420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Newson updated COUCHDB-1420: --- Component/s: (was: Database Core) Priority: Minor (was: Major) Summary: Futon display breaks on really long db name (was: Reject databases with names longer than typical filename limit) will put that in a new ticket, reverting this to original purpose. Futon display breaks on really long db name --- Key: COUCHDB-1420 URL: https://issues.apache.org/jira/browse/COUCHDB-1420 Project: CouchDB Issue Type: Bug Components: Futon Affects Versions: 1.2 Reporter: Sam Bisbee Priority: Minor Futon's display breaks if the database name is too long and some information is just not retrieved. Example database name: bpjwguulsnozjugktpmtnsucxlojprxyhbmuxkyuqepaptmjvwctautgpiawxiodsqkdrposfrdayauvzkgixkztdaamhhihifdvdqykpqacpmifosdouzlqwxkbooxnebxohdueppgpawfsetsayrzeigevclmnplfewskbzepwqkrpuvsqeqkdnmkgxwrsmdqmgcqkhfkgtnfmcompyugwmymaoguzxwfjn Marking minor since people who want db names this long/crazy are (a) a minority and (b) should be accepting of minor UI issues. Cheers. -- 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: [VOTE] Apache CouchDB 1.2.0 release, second round
On Feb 23, 2012, at 19:47 , Filipe David Manana wrote: On Thu, Feb 23, 2012 at 9:09 AM, Jan Lehnardt j...@apache.org wrote: On Feb 23, 2012, at 00:28 , Noah Slater wrote: Hello, I would like call a vote for the Apache CouchDB 1.2.0 release, second round. We encourage the whole community to download and test these release artifacts so that any critical issues can be resolved before the release is made. Everyone is free to vote on this release, so get stuck in! We are voting on the following release artifacts: http://people.apache.org/~nslater/dist/1.2.0/ These artifacts have been built from the following tree-ish in Git: 4cd60f3d1683a3445c3248f48ae064fb573db2a1 Please follow the test procedure before voting: http://wiki.apache.org/couchdb/Test_procedure Thank you. Happy voting, Signature and hashes check out. Mac OS X 10.7.3, 64bit, SpiderMonkey 1.8.0, Erlang R14B04: make check works fine, browser tests in Safari work fine. Mac OS X 10.7.3, 64bit, SpiderMonkey 1.8.5, Erlang R14B04: make check works fine, browser tests in Safari work fine. FreeBSD 9.0, 64bit, SpiderMonkey 1.7.0, Erlang R14B04: make check works fine, browser tests in Safari work fine. CentOS 6.2, 64bit, SpiderMonkey 1.8.5, Erlang R14B04: make check works fine, browser tests in Firefox work fine. Ubuntu 11.4, 64bit, SpiderMonkey 1.8.5, Erlang R14B02: make check works fine, browser tests in Firefox work fine. Ubuntu 10.4, 32bit, SpiderMonkey 1.8.0, Erlang R13B03: make check fails in - 076-file-compression.t: https://gist.github.com/1893373 - 220-compaction-daemon.t: https://gist.github.com/1893387 This on runs in a VM and is 32bit, so I don't know if there's anything in the tests that rely on 64bittyness or the R14B03. Filipe, I think you worked on both features, do you have an idea? The compression fails because snappy NIF needs R13B04+ (forgot to update the test to work with R13B03 and below). For the compaction one, on ubuntu/debian you need to install the package 'erlang-os-mon' Thanks for the update Filipe! My +1 stands :) Cheers Jan --
Re: [VOTE] Apache CouchDB 1.2.0 release, second round
+1 (checks passed on Arch Linux 3.2.6 64bit, R14B04, Spidermonkey 1.8.5) On Wednesday, February 22, 2012 at 23:39 , Brian Mitchell wrote: Same result as last vote on OS X 10.7.3 using Erlang OTP R15B and spidermonkey 1.8.5 . `make check` hangs on 076-file-compression.t and passes in the browser as long as I'm in private browsing mode or have the cache disabled. I'll do a test on Linux tomorrow with R14B04 before I +1. Brian. On Wednesday, February 22, 2012 at 18:28 , Noah Slater wrote: Hello, I would like call a vote for the Apache CouchDB 1.2.0 release, second round. We encourage the whole community to download and test these release artifacts so that any critical issues can be resolved before the release is made. Everyone is free to vote on this release, so get stuck in! We are voting on the following release artifacts: http://people.apache.org/~nslater/dist/1.2.0/ These artifacts have been built from the following tree-ish in Git: 4cd60f3d1683a3445c3248f48ae064fb573db2a1 Please follow the test procedure before voting: http://wiki.apache.org/couchdb/Test_procedure Thank you. Happy voting, N
Re: [VOTE] Apache CouchDB 1.2.0 release, second round
sorry Noah, I'm in debug mode today so I don't care to start mucking with my stack, recompiling erlang, etc... I did try using that build repeatedly and it crashes all the time. I find it very odd and I had seen those before as I said on my older macbook. I do see the hangs Jan describes in the etaps, they have been there right along, so I'm confident this just the SSL issue. Why it only happens on the build is puzzling, any source build of any branch works just peachy. So I'd say I'm +1 based on my use of the 1.2.x branch but I'd like to hear from Stefan, who reported the severe performance regression. BobN seems to think we can ignore that, it's something flaky in that fellow's environment. I tend to agree but I'm conservative On Feb 23, 2012, at 1:23 PM, Noah Slater wrote: Can someone convince me this bus error stuff and segfaults is not a blocking issue. Bob tells me that he's followed the steps above and he's still experiencing the issues. Bob, you did follow the steps to install your own SSL right? On Thu, Feb 23, 2012 at 5:09 PM, Jan Lehnardt j...@apache.org wrote: On Feb 23, 2012, at 00:28 , Noah Slater wrote: Hello, I would like call a vote for the Apache CouchDB 1.2.0 release, second round. We encourage the whole community to download and test these release artifacts so that any critical issues can be resolved before the release is made. Everyone is free to vote on this release, so get stuck in! We are voting on the following release artifacts: http://people.apache.org/~nslater/dist/1.2.0/ These artifacts have been built from the following tree-ish in Git: 4cd60f3d1683a3445c3248f48ae064fb573db2a1 Please follow the test procedure before voting: http://wiki.apache.org/couchdb/Test_procedure Thank you. Happy voting, Signature and hashes check out. Mac OS X 10.7.3, 64bit, SpiderMonkey 1.8.0, Erlang R14B04: make check works fine, browser tests in Safari work fine. Mac OS X 10.7.3, 64bit, SpiderMonkey 1.8.5, Erlang R14B04: make check works fine, browser tests in Safari work fine. FreeBSD 9.0, 64bit, SpiderMonkey 1.7.0, Erlang R14B04: make check works fine, browser tests in Safari work fine. CentOS 6.2, 64bit, SpiderMonkey 1.8.5, Erlang R14B04: make check works fine, browser tests in Firefox work fine. Ubuntu 11.4, 64bit, SpiderMonkey 1.8.5, Erlang R14B02: make check works fine, browser tests in Firefox work fine. Ubuntu 10.4, 32bit, SpiderMonkey 1.8.0, Erlang R13B03: make check fails in - 076-file-compression.t: https://gist.github.com/1893373 - 220-compaction-daemon.t: https://gist.github.com/1893387 This on runs in a VM and is 32bit, so I don't know if there's anything in the tests that rely on 64bittyness or the R14B03. Filipe, I think you worked on both features, do you have an idea? I tried running it all through Erlang R15B on Mac OS X 1.7.3, but a good way into `make check` the tests would just stop and hang. The last time, repeatedly in 160-vhosts.t, but when run alone, that test finished in under five seconds. I'm not sure what the issue is here. Despite the things above, I'm happy to give this a +1 if we put a warning about R15B on the download page. Great work all! Cheers Jan --
Re: [VOTE] Apache CouchDB 1.2.0 release, second round
I should clarify that I didn't mean ignore, but a test on virtual machines, of unknown provenance, that are merely similar is enough to make me very suspicious of any benchmark. If anyone wanted to perform a more rigorous and diligent test (like, say, *only* changing the couchdb source code between identical test runs), then I'd certainly want to halt the release if the 1/10th result were confirmed. b. On 23 February 2012 22:25, Bob Dionne dio...@dionne-associates.com wrote: sorry Noah, I'm in debug mode today so I don't care to start mucking with my stack, recompiling erlang, etc... I did try using that build repeatedly and it crashes all the time. I find it very odd and I had seen those before as I said on my older macbook. I do see the hangs Jan describes in the etaps, they have been there right along, so I'm confident this just the SSL issue. Why it only happens on the build is puzzling, any source build of any branch works just peachy. So I'd say I'm +1 based on my use of the 1.2.x branch but I'd like to hear from Stefan, who reported the severe performance regression. BobN seems to think we can ignore that, it's something flaky in that fellow's environment. I tend to agree but I'm conservative On Feb 23, 2012, at 1:23 PM, Noah Slater wrote: Can someone convince me this bus error stuff and segfaults is not a blocking issue. Bob tells me that he's followed the steps above and he's still experiencing the issues. Bob, you did follow the steps to install your own SSL right? On Thu, Feb 23, 2012 at 5:09 PM, Jan Lehnardt j...@apache.org wrote: On Feb 23, 2012, at 00:28 , Noah Slater wrote: Hello, I would like call a vote for the Apache CouchDB 1.2.0 release, second round. We encourage the whole community to download and test these release artifacts so that any critical issues can be resolved before the release is made. Everyone is free to vote on this release, so get stuck in! We are voting on the following release artifacts: http://people.apache.org/~nslater/dist/1.2.0/ These artifacts have been built from the following tree-ish in Git: 4cd60f3d1683a3445c3248f48ae064fb573db2a1 Please follow the test procedure before voting: http://wiki.apache.org/couchdb/Test_procedure Thank you. Happy voting, Signature and hashes check out. Mac OS X 10.7.3, 64bit, SpiderMonkey 1.8.0, Erlang R14B04: make check works fine, browser tests in Safari work fine. Mac OS X 10.7.3, 64bit, SpiderMonkey 1.8.5, Erlang R14B04: make check works fine, browser tests in Safari work fine. FreeBSD 9.0, 64bit, SpiderMonkey 1.7.0, Erlang R14B04: make check works fine, browser tests in Safari work fine. CentOS 6.2, 64bit, SpiderMonkey 1.8.5, Erlang R14B04: make check works fine, browser tests in Firefox work fine. Ubuntu 11.4, 64bit, SpiderMonkey 1.8.5, Erlang R14B02: make check works fine, browser tests in Firefox work fine. Ubuntu 10.4, 32bit, SpiderMonkey 1.8.0, Erlang R13B03: make check fails in - 076-file-compression.t: https://gist.github.com/1893373 - 220-compaction-daemon.t: https://gist.github.com/1893387 This on runs in a VM and is 32bit, so I don't know if there's anything in the tests that rely on 64bittyness or the R14B03. Filipe, I think you worked on both features, do you have an idea? I tried running it all through Erlang R15B on Mac OS X 1.7.3, but a good way into `make check` the tests would just stop and hang. The last time, repeatedly in 160-vhosts.t, but when run alone, that test finished in under five seconds. I'm not sure what the issue is here. Despite the things above, I'm happy to give this a +1 if we put a warning about R15B on the download page. Great work all! Cheers Jan --
Re: [VOTE] Apache CouchDB 1.2.0 release, second round
On Feb 23, 2012, at 00:28 , Noah Slater wrote: Hello, I would like call a vote for the Apache CouchDB 1.2.0 release, second round. We encourage the whole community to download and test these release artifacts so that any critical issues can be resolved before the release is made. Everyone is free to vote on this release, so get stuck in! We are voting on the following release artifacts: http://people.apache.org/~nslater/dist/1.2.0/ These artifacts have been built from the following tree-ish in Git: 4cd60f3d1683a3445c3248f48ae064fb573db2a1 Please follow the test procedure before voting: http://wiki.apache.org/couchdb/Test_procedure +1 md5, sha, sig OK diff OK Windows 7 Enterprise x64 firefox 6.01 both R14B04 and R15B OpenSSL 0.9.8r SpiderMonkey 1.8.5 ICU 4.6.1 curl 7.23.1 - make check n/a binaries from https://people.apache.org/~dch/dist/1.2.0/ - both sigs OK - no malware found - user verification OK - futon OK Linux Mint LMDE x64 R14B03 ICU 4.4.2 OpenSSL 1.0.0d Spidermonkey libmozjs5d (JavaScript-C 1.8.0 pre-release 1 2007-10-03) - make distcheck OK - make check OK Firefox 9.0.1 - user verification OK - futon OK A+ Dave
Re: [VOTE] Apache CouchDB 1.2.0 release, second round
Are you going to call a separate vote on these Dave? On Thu, Feb 23, 2012 at 11:07 PM, Dave Cottlehuber d...@muse.net.nz wrote: On Feb 23, 2012, at 00:28 , Noah Slater wrote: Hello, I would like call a vote for the Apache CouchDB 1.2.0 release, second round. We encourage the whole community to download and test these release artifacts so that any critical issues can be resolved before the release is made. Everyone is free to vote on this release, so get stuck in! We are voting on the following release artifacts: http://people.apache.org/~nslater/dist/1.2.0/ These artifacts have been built from the following tree-ish in Git: 4cd60f3d1683a3445c3248f48ae064fb573db2a1 Please follow the test procedure before voting: http://wiki.apache.org/couchdb/Test_procedure +1 md5, sha, sig OK diff OK Windows 7 Enterprise x64 firefox 6.01 both R14B04 and R15B OpenSSL 0.9.8r SpiderMonkey 1.8.5 ICU 4.6.1 curl 7.23.1 - make check n/a binaries from https://people.apache.org/~dch/dist/1.2.0/ - both sigs OK - no malware found - user verification OK - futon OK Linux Mint LMDE x64 R14B03 ICU 4.4.2 OpenSSL 1.0.0d Spidermonkey libmozjs5d (JavaScript-C 1.8.0 pre-release 1 2007-10-03) - make distcheck OK - make check OK Firefox 9.0.1 - user verification OK - futon OK A+ Dave
[jira] [Created] (COUCHDB-1421) Wrong X-Forwarded-For address chosen as peer?
Wrong X-Forwarded-For address chosen as peer? --- Key: COUCHDB-1421 URL: https://issues.apache.org/jira/browse/COUCHDB-1421 Project: CouchDB Issue Type: Bug Reporter: Nathan Vander Wilt I noticed that in the Mochiweb code, it uses the last item of the X-Forwarded-For list as the peer: https://github.com/apache/couchdb/blob/master/src/mochiweb/mochiweb_request.erl#L82 But shouldn't this snag the *first* item of the list instead? http://tools.ietf.org/html/draft-petersson-forwarded-for-02#section-5.2 says the first for-parameter will disclose the user agent where the request first was made — the user agent is what I'd want as an app developer, not the second-nearest proxy. -- 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: Couchbase trademark issues
On Mon, Feb 20, 2012 at 7:12 AM, Robert Newson rnew...@apache.org wrote: coinciding with the 1.2 release would be awesome On 20 February 2012 12:09, Robert Newson rnew...@apache.org wrote: 1 for a revamped couchdb.apache.org. The most recent change, I think, was mine, which simply dropped the misleading diagram in the top-right. Long past time for an overhaul. Who has the time and skill to make this happen? as one potential drop in that bucket, i spent some time fiddling with the wiki's css to bring it more in line with the project's color scheme. i also took the liberty of tweaking the typography a bit. here's a demo (based on what i was able to wget of the site): http://samizdat.cc/couchdb/ all the modifications can be found in: http://samizdat.cc/moin_static188/modernized/css/screen.css except for the header image which lives at: http://samizdat.cc/moin_static188/modernized/img/couchdb-wiki-logo-small.png -christian
Re: Couchbase trademark issues
I like this look, crisper and easier to read. Nice work On Feb 23, 2012, at 9:20 PM, Christian Swinehart wrote: On Mon, Feb 20, 2012 at 7:12 AM, Robert Newson rnew...@apache.org wrote: coinciding with the 1.2 release would be awesome On 20 February 2012 12:09, Robert Newson rnew...@apache.org wrote: 1 for a revamped couchdb.apache.org. The most recent change, I think, was mine, which simply dropped the misleading diagram in the top-right. Long past time for an overhaul. Who has the time and skill to make this happen? as one potential drop in that bucket, i spent some time fiddling with the wiki's css to bring it more in line with the project's color scheme. i also took the liberty of tweaking the typography a bit. here's a demo (based on what i was able to wget of the site): http://samizdat.cc/couchdb/ all the modifications can be found in: http://samizdat.cc/moin_static188/modernized/css/screen.css except for the header image which lives at: http://samizdat.cc/moin_static188/modernized/img/couchdb-wiki-logo-small.png -christian
