Bacchus, reviens, ils sont devenus fous !
Version en ligne http://mailing.vinsprimeurs.com/rclickr.asp?click_id_cmp=3473click_ema il=couchdb-dev%40incubator.apache.orgclick_diug=1355a90fb5ab56f7ba9b009 5f83760f1click_url=http://www.vinomedia.fr/lettre-vinomedia/lettre-vino media_20120402.htm bandeau Lettre Vinomediahttp://www.vinomedia.fr/lettre-vinomedia/email/images/bandeauL V.jpg le 2 avril 2012 Edito de Benoit Escoffier Ouvrir en pdf http://mailing.vinsprimeurs.com/rclickr.asp?click_id_cmp=3473click_ema il=couchdb-dev%40incubator.apache.orgclick_diug=1355a90fb5ab56f7ba9b009 5f83760f1click_url=http://www.vinomedia.fr/lettre-vinomedia/editos/2012 -EDITO-2-AVRIL.pdf Partager la lettre sur Facebook https://www.facebook.com/sharer/sharer.php?u=http://www.vinomedia.fr/le ttre-vinomedia/lettre-vinomedia_20120402.htmt=Lettre+Vinomediasrc=sp Rubrique L'info du vin http://mailing.vinsprimeurs.com/rclickr.asp?click_id_cmp=3473click_ema il=couchdb-dev%40incubator.apache.orgclick_diug=1355a90fb5ab56f7ba9b009 5f83760f1click_url=http://www.vinomedia.fr/lettre-vinomedia/info-du-vin .html de Vinomedia Aperçu des communiqués de presse mis en ligne cette semaine : Bacchus, reviens, ils sont devenus fous ! Décidément, le monde tourne à lenvers. Que se passe-t-il dans la tête de nos représentants dassociations de protection et de lutte contre les addictions ? En reprenant les termes de notre confrère du journal « La vigne », les antialcools veulent une mention choc sur les bouteilles. Là où lon peut leur donner raison sous couvert de la prévention quand on parle dabus de consommation, on ne peut que leur donner tort quand on parle du produit. Il se trouve que toutes les associations ( alliance prévention alcool), nont pas pu enrayer laugmentation de la consommation dalcool chez les jeunes, malgré leurs coups de boutoirs permanents contre les faux coupables. Nous ne pouvons pas contester la trop grande consommation dalcool chez les jeunes, mais je mets en doute que cette consommation se résume à la prise exagérée de vin. Les faux arguments pour régler ce problème deviennent délirants : 92% des personnes interrogées déclarent que « lalcool est dangereux pour la santé ». Comment peut-on arriver à se réfugier derrière une telle aberration ? Si ce sondage reflétait la réalité, il ny aurait plus de problème puisque notre société serait devenue aseptisée. Les bienfaits du Vinhttp://www.vinomedia.fr/lettre-vinomedia/email/images/pasteur.jpg A ce compte là, manger est dangereux, conduire est dangereux, dormir est dangereux, vivre est dangereux ! Et par la même occasion, traitons PASTEUR de fou, lui qui indiquait que le vin était le meilleur des remèdes. Il faut que la profession viticole prenne conscience quaprès sen être pris aux abus de consommation, lon sen prend maintenant au produit, et ce combat va mener à son éradication. En période électorale, certains candidats inconnus ont obtenus 500 parrainages. Si un jour 500 maires viticulteurs voulaient donner leur parrainage à un porte parole de la profession pour faire entendre la voix de la raison, avec le même temps de parole que nos grands leaders, peut-être obtiendrions nous des résultats plus probants dans la défense du produit, du terroir ainsi que la protection de la jeunesse. Benoit Escoffier bescoff...@vinomedia.fr mailto:bescoff...@vinomedia.fr www.vinomedia.fr http://www.vinomedia.fr/ http://mailing.vinsprimeurs.com/rclickr.asp?click_id_cmp=3473click_ema il=couchdb-dev%40incubator.apache.orgclick_diug=1355a90fb5ab56f7ba9b009 5f83760f1click_url=http://www.vinomedia.fr/salons/particulier/inscripti on.asp Guide Vignobles et Tourisme http://mailing.vinsprimeurs.com/rclickr.asp?click_id_cmp=3473click_ema il=couchdb-dev%40incubator.apache.orgclick_diug=1355a90fb5ab56f7ba9b009 5f83760f1click_url=http://www.vinomedia-publishing.com/produit.asp?pr_i d_produit=61 Nos Prochains Salons prochains salonshttp://www.vinomedia.fr/lettre-vinomedia/email/images/prochains-s alons20120402.jpg Découvrez nos bases de données viticoles http://mailing.vinsprimeurs.com/rclickr.asp?click_id_cmp=3473click_ema il=couchdb-dev%40incubator.apache.orgclick_diug=1355a90fb5ab56f7ba9b009 5f83760f1click_url=http://www.vinomedia-publishing.com/bases-de-donnees .asp - PRESSE - CAVISTES - DISTRIBUTEURS - EPICERIES FINES - CAVES COOPERATIVES - NEGOCIANTS - PRODUCTEURS - AMATEURS DE VIN... - CP PRIMEURS BAN DU MILLESIME http://www.vinomedia.fr/lettre-vinomedia/communiques/2012_03/20120402/C P%20PRIMEURS%20BAN%20DU%20MILLESIME.pdf - Crus Bourgeois du Médoc - Mars 2012 N°2- FR VDEF http://www.vinomedia.fr/lettre-vinomedia/communiques/2012_03/20120402/C rus%20Bourgeois%20du%20Médoc%20-%20Mars%202012%20N°2-%20FR%20VDEF.pdf - La Fleur de Boüard Communiqué de presse http://www.vinomedia.fr/lettre-vinomedia/communiques/2012_03/20120402/L a%20Fleur%20de%20Boüard%20Communiqué%20de%20presse.pdf - Lauréats du Trophée de la Presse des Grands Jours de Bourgogne
Re: When will BigCouch be merged into Apache Couchdb?
Hi Sean, There are definitely some things to work out, and we've been very deliberate in thinking them over carefully. Next week we're having a dev meeting in Boston and I'm hopeful one of the deliverables from that meeting will be a more concrete design/plan for this integration. Cheers, Bob On Apr 2, 2012, at 10:48 AM, Sean Copenhaver wrote: I do have some concerns over this. If I remember correctly there are a couple of API incompatibilities. Will there be any compatibility issues? Is BigCouch going to be an optional clustering component/plugin piece? -- Sean Copenhaver On Monday, April 2, 2012 at 10:32 AM, Adam Kocoloski wrote: On Apr 2, 2012, at 10:28 AM, Mike Kimber wrote: Can anyone able to provide an ETA as to when BigCouch be merged into Apache Couchdb? Or if not provide any idea what the migration might be from BigCouch to the merged code base? Juts trying to worm out if I should wait for the code merge or move to BigCouch now. Thanks Mike Hi Mike, I'm afraid we're still firming up an ETA. I wouldn't anticipate any major issues migrating from a BigCouch install to a future Apache CouchDB install incorporating the BigCouch feature set. Regards, Adam
Re: [VOTE] Apache CouchDB 1.2.0 release, fifth round
On 03/29/2012 03:02 PM, Noah Slater wrote: Hello, I would like call a vote for the Apache CouchDB 1.2.0 release, fifth round. Changes since last round: - Fixed the release procedure I am calling this the Sisyphus release. 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: e736fa9e314034e2603ac5861692ddeab92f1dad Please follow the test procedure before voting: http://wiki.apache.org/couchdb/Test_procedure Thank you. Happy voting, N Looks great! +1 Fedora 16 32bit, Erlang R14B, Spidermonkey 1.8.5, etap tests pass, browser tests pass Centos 6 64bit, Erlang R14B, Spidermonkey 1.8.5, etap tests pass, browser tests pass Centos 6 32bit, Erlang R14B, Spidermonkey 1.8.5, etap tests pass, browser tests pass Centos 6 builds and passes agains Spidermonkey 1.7, current stable, but is crazy slow. No reason to run this. spec for Fedora works without modification. Wendall
Re: [VOTE] Apache CouchDB 1.2.0 release, fifth round
+1 signatures: ok make check: ok browser tests: ok (FF 11.0) System: OS X 10.7.3, R15B, SpiderMonkey 1.8.5 On 30.03.2012, at 00:02, Noah Slater wrote: Hello, I would like call a vote for the Apache CouchDB 1.2.0 release, fifth round. Changes since last round: - Fixed the release procedure I am calling this the Sisyphus release. 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: e736fa9e314034e2603ac5861692ddeab92f1dad Please follow the test procedure before voting: http://wiki.apache.org/couchdb/Test_procedure Thank you. Happy voting, N
[jira] [Created] (COUCHDB-1453) Replicator fails with use_users_db = false
Replicator fails with use_users_db = false
--
Key: COUCHDB-1453
URL: https://issues.apache.org/jira/browse/COUCHDB-1453
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.2
Environment: Centos 6 32bit, Erlang R14B, Spidermonkey 1.8.5
Reporter: Wendall Cada
If I create a new replication document in _replicate like this:
{
source: http://localhost:5990/users;,
target: users_backup,
create_target: true,
continuous: true
}
Creation of DB fails with:
unauthorized to access or create database users_backup
If I manually create this database, and set create_target to false, replication
completes, but generates errors while processing the update_sequence like this:
Replicator: couldn't write document `_design/lck`, revision
`2-8edc91dec975f893efdc6f440286c79e`, to target database `users_backup`. Error:
`unauthorized`, reason: `You are not a db or server admin.`.
--
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-1453) Replicator fails with use_users_db = false
[
https://issues.apache.org/jira/browse/COUCHDB-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244842#comment-13244842
]
Wendall Cada commented on COUCHDB-1453:
---
After creating the database, view documents fail to sync. This would account
for the second error after creating the database.
Replicator fails with use_users_db = false
--
Key: COUCHDB-1453
URL: https://issues.apache.org/jira/browse/COUCHDB-1453
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.2
Environment: Centos 6 32bit, Erlang R14B, Spidermonkey 1.8.5
Reporter: Wendall Cada
If I create a new replication document in _replicate like this:
{
source: http://localhost:5990/users;,
target: users_backup,
create_target: true,
continuous: true
}
Creation of DB fails with:
unauthorized to access or create database users_backup
If I manually create this database, and set create_target to false,
replication completes, but generates errors while processing the
update_sequence like this:
Replicator: couldn't write document `_design/lck`, revision
`2-8edc91dec975f893efdc6f440286c79e`, to target database `users_backup`.
Error: `unauthorized`, reason: `You are not a db or server admin.`.
--
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-1453) Replicator fails with use_users_db = false
[
https://issues.apache.org/jira/browse/COUCHDB-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244860#comment-13244860
]
Filipe Manana commented on COUCHDB-1453:
Try adding an explicit user_ctx property to the replication document:
{
source: ...,
...,
user_ctx: { roles: [ _admin] }
}
Database creation and design document update/creation/deletion requires admin
privilege. This is documented somewhere in the wiki.
Replicator fails with use_users_db = false
--
Key: COUCHDB-1453
URL: https://issues.apache.org/jira/browse/COUCHDB-1453
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.2
Environment: Centos 6 32bit, Erlang R14B, Spidermonkey 1.8.5
Reporter: Wendall Cada
If I create a new replication document in _replicate like this:
{
source: http://localhost:5990/users;,
target: users_backup,
create_target: true,
continuous: true
}
Creation of DB fails with:
unauthorized to access or create database users_backup
If I manually create this database, and set create_target to false,
replication completes, but generates errors while processing the
update_sequence like this:
Replicator: couldn't write document `_design/lck`, revision
`2-8edc91dec975f893efdc6f440286c79e`, to target database `users_backup`.
Error: `unauthorized`, reason: `You are not a db or server admin.`.
--
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-1453) Replicator fails with use_users_db = false
[
https://issues.apache.org/jira/browse/COUCHDB-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filipe Manana closed COUCHDB-1453.
--
Resolution: Invalid
Replicator fails with use_users_db = false
--
Key: COUCHDB-1453
URL: https://issues.apache.org/jira/browse/COUCHDB-1453
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.2
Environment: Centos 6 32bit, Erlang R14B, Spidermonkey 1.8.5
Reporter: Wendall Cada
If I create a new replication document in _replicate like this:
{
source: http://localhost:5990/users;,
target: users_backup,
create_target: true,
continuous: true
}
Creation of DB fails with:
unauthorized to access or create database users_backup
If I manually create this database, and set create_target to false,
replication completes, but generates errors while processing the
update_sequence like this:
Replicator: couldn't write document `_design/lck`, revision
`2-8edc91dec975f893efdc6f440286c79e`, to target database `users_backup`.
Error: `unauthorized`, reason: `You are not a db or server admin.`.
--
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: [jira] [Commented] (COUCHDB-1453) Replicator fails with use_users_db = false
Thanks Filipe for the feedback.
This may be invalid, but documentation is so far behind now, I'm never
sure what is expected behavior and what is a bug. Every new feature from
the last 1+ years is either poorly documented, or not documented at all.
Luckily, I typically use a base feature set that I've been happy with
since 0.10.x. This was a case of trying a new feature, reading the
documentation, and finding that it was not really documented at all.
Wendall
On 04/02/2012 05:01 PM, Filipe Manana (Commented) (JIRA) wrote:
[
https://issues.apache.org/jira/browse/COUCHDB-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244860#comment-13244860
]
Filipe Manana commented on COUCHDB-1453:
Try adding an explicit user_ctx property to the replication document:
{
source: ...,
...,
user_ctx: { roles: [ _admin] }
}
Database creation and design document update/creation/deletion requires admin
privilege. This is documented somewhere in the wiki.
Replicator fails with use_users_db = false
--
Key: COUCHDB-1453
URL: https://issues.apache.org/jira/browse/COUCHDB-1453
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.2
Environment: Centos 6 32bit, Erlang R14B, Spidermonkey 1.8.5
Reporter: Wendall Cada
If I create a new replication document in _replicate like this:
{
source: http://localhost:5990/users;,
target: users_backup,
create_target: true,
continuous: true
}
Creation of DB fails with:
unauthorized to access or create database users_backup
If I manually create this database, and set create_target to false, replication
completes, but generates errors while processing the update_sequence like this:
Replicator: couldn't write document `_design/lck`, revision
`2-8edc91dec975f893efdc6f440286c79e`, to target database `users_backup`. Error:
`unauthorized`, reason: `You are not a db or server admin.`.
--
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-1453) Replicator fails with use_users_db = false
[
https://issues.apache.org/jira/browse/COUCHDB-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244879#comment-13244879
]
Filipe Manana commented on COUCHDB-1453:
Wendall, it's documented in a gist mentioned at:
http://wiki.apache.org/couchdb/Replication#Replicator_database
Gist: https://gist.github.com/832610 (section 8)
Replicator fails with use_users_db = false
--
Key: COUCHDB-1453
URL: https://issues.apache.org/jira/browse/COUCHDB-1453
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.2
Environment: Centos 6 32bit, Erlang R14B, Spidermonkey 1.8.5
Reporter: Wendall Cada
If I create a new replication document in _replicate like this:
{
source: http://localhost:5990/users;,
target: users_backup,
create_target: true,
continuous: true
}
Creation of DB fails with:
unauthorized to access or create database users_backup
If I manually create this database, and set create_target to false,
replication completes, but generates errors while processing the
update_sequence like this:
Replicator: couldn't write document `_design/lck`, revision
`2-8edc91dec975f893efdc6f440286c79e`, to target database `users_backup`.
Error: `unauthorized`, reason: `You are not a db or server admin.`.
--
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: [jira] [Commented] (COUCHDB-1453) Replicator fails with use_users_db = false
I read this gist before creating the ticket. The documentation states
that it *can contain user_ctx. No indication that this is required if I
have use_users_db = false. I'm not sure that this isn't a bug as, it
requires a component to use the baked in _users auth stuff, even though
I've intentionally configured my database to not use this. This is a
change in behavior from what I've expected with couchdb in the past. So
now, even if I have use_users_db = false, I still have to be aware of
how _users works to understand implications of permissions failures.
Wendall
On 04/02/2012 05:39 PM, Filipe Manana (Commented) (JIRA) wrote:
[
https://issues.apache.org/jira/browse/COUCHDB-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244879#comment-13244879
]
Filipe Manana commented on COUCHDB-1453:
Wendall, it's documented in a gist mentioned at:
http://wiki.apache.org/couchdb/Replication#Replicator_database
Gist: https://gist.github.com/832610 (section 8)
Replicator fails with use_users_db = false
--
Key: COUCHDB-1453
URL: https://issues.apache.org/jira/browse/COUCHDB-1453
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.2
Environment: Centos 6 32bit, Erlang R14B, Spidermonkey 1.8.5
Reporter: Wendall Cada
If I create a new replication document in _replicate like this:
{
source: http://localhost:5990/users;,
target: users_backup,
create_target: true,
continuous: true
}
Creation of DB fails with:
unauthorized to access or create database users_backup
If I manually create this database, and set create_target to false, replication
completes, but generates errors while processing the update_sequence like this:
Replicator: couldn't write document `_design/lck`, revision
`2-8edc91dec975f893efdc6f440286c79e`, to target database `users_backup`. Error:
`unauthorized`, reason: `You are not a db or server admin.`.
--
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: [jira] [Created] (COUCHDB-1453) Replicator fails with use_users_db = false
On Tuesday, April 3, 2012, Wendall Cada wrote:
I read this gist before creating the ticket. The documentation states that
it *can contain user_ctx. No indication that this is required if I have
use_users_db = false. I'm not sure that this isn't a bug as, it requires a
component to use the baked in _users auth stuff, even though I've
intentionally configured my database to not use this. This is a change in
behavior from what I've expected with couchdb in the past. So now, even if
I have use_users_db = false, I still have to be aware of how _users works
to understand implications of permissions failures.
The parameter use_users_db is related to the oauth authentication handler
(and new in 1.2). It's under the section couch_httpd_oauth. Doesn't apply
to anything else except oauth handler.
Wendall
On 04/02/2012 05:39 PM, Filipe Manana (Commented) (JIRA) wrote:
[ https://issues.apache.org/**jira/browse/COUCHDB-1453?page=**
com.atlassian.jira.plugin.**system.issuetabpanels:comment-**
tabpanelfocusedCommentId=**13244879#comment-13244879https://issues.apache.org/jira/browse/COUCHDB-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244879#comment-13244879]
Filipe Manana commented on COUCHDB-1453:
--**--
Wendall, it's documented in a gist mentioned at:
http://wiki.apache.org/**couchdb/Replication#**Replicator_databasehttp://wiki.apache.org/couchdb/Replication#Replicator_database
Gist: https://gist.github.com/832610 (section 8)
Replicator fails with use_users_db = false
--**
Key: COUCHDB-1453
URL: https://issues.apache.org/**
jira/browse/COUCHDB-1453https://issues.apache.org/jira/browse/COUCHDB-1453
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.2
Environment: Centos 6 32bit, Erlang R14B, Spidermonkey 1.8.5
Reporter: Wendall Cada
If I create a new replication document in _replicate like this:
{
source: http://localhost:5990/users;,
target: users_backup,
create_target: true,
continuous: true
}
Creation of DB fails with:
unauthorized to access or create database users_backup
If I manually create this database, and set create_target to false,
replication completes, but generates errors while processing the
update_sequence like this:
Replicator: couldn't write document `_design/lck`, revision `2-**
8edc91dec975f893efdc6f440286c7**9e`, to target database `users_backup`.
Error: `unauthorized`, reason: `You are not a db or server admin.`.
--
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.**jspahttps://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/**
software/jira http://www.atlassian.com/software/jira
--
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.
