Re: [DISCUSS] Erlang version update process for convenience binaries

[Dave Cottlehuber]

On Wed, 12 Jan 2022, at 18:39, Adam Kocoloski wrote:
> Hi,
>
> Our convenience binaries are using Erlang 20, and we are now seeing 
> users file bug reports for issues that have been fixed by the Erlang 
> team more than 3 years ago :( In recent years the Erlang/OTP team has 
> accelerated their release cycles, and we are now _way_ behind the 
> current Erlang 24.2 release.

Overall I agree we should fix this. Since switching ~ 2-3 years ago
to tracking very latest OTP releases, I've reported a couple of severe
core-dumping bugs upstream and they have been dealt with promptly. Even
on my admittedly obscure setup, on the bleeding pre-release edge of OTP.

I don't think we take major risks from tracking at N-1 (i.e. OTP 23 & 24)
in general. I think most of the wider BEAM community tracks latest OTP
since the JIT anyway. It is absolutely a major change, and it's worth us
switching to that by default everywhere if we can.

> I took a peek at the RabbitMQ official image history, and it seems the 
> Docker folks are rebuilding and publishing images for supported 
> RabbitMQ versions to use the newest Erlang/OTP on the day it’s 
> released. That’s aggressive! But I am thinking that we might want to 
> head toward that general direction and give users a CouchDB install 
> that packages the current Erlang version by default.

On FreeBSD, we do pretty much the same, not *quite* as fast as those
mad hatter bunnies though.

OTP updates land in FreeBSD typically less than a fortnight after
publication, and 2-5 days later that is in our CouchDB packages too.

I have kept a close eye out on the errata patches (tag releases, every
few weeks), and gut feel says it's a win to keep up to date.

FreeBSD is shipping latest OTP24 for CouchDB, and nobody has thrown
anything at me yet.

> One question I had in my head was whether to publish packages / images 
> for multiple major Erlang versions, but it doesn’t seem to be a common 
> practice.

No. The number of people who are shipping CouchDB+custom OTP code must
be vanishingly small, and those people should be capable of raising
questions here for assistance. It also makes more work for packagers.

> I also wondered whether to pin a given CouchDB release to an Erlang 
> release series, e.g. CouchDB 3.2.0 packages are built against the 
> latest Erlang 20 patch release, while 3.2.1 could jump to Erlang 24. I 
> think the cognitive load for debugging support tickets might be lower 
> in that approach. What do you think?

I can't speak for elsewhere, but generally sticking to latest OTP is
the least work in general from my perspective.

A+
Dave

Re: [VOTE] Release Apache CouchDB 3.2.0

[Dave Cottlehuber]

On Thu, 30 Sep 2021, at 16:44, Nick Vatamaniuc wrote:
> Thanks everyone for verifying
>
> RC1 voting fails and we will issue an other release candidate
>
> So far the issues are:
>   3) couch_prometheus_e2e_tests:109: deny_prometheus_http...*failed* :
> this looks like a network stack issue difference. We test that when we

Once I disabled all my extreme-tinfoil-network-security defaults, #3 is
resolved. We can drop that off the list.

A+
Dave

Re: [VOTE] Release Apache CouchDB 3.2.0

[Dave Cottlehuber]

On Mon, 27 Sep 2021, at 22:59, Nick Vatamaniuc wrote:
> Dear community,
>
> I would like to propose that we release Apache CouchDB 3.2.0.
>
> Candidate release notes:
>
> https://docs.couchdb.org/en/latest/whatsnew/3.2.html
>
> We encourage the whole community to download and test these release
> artefacts so that any critical issues can be resolved before the
> release is made. Everyone is free to vote on this release, so dig
> right in! (Only PMC members have binding votes, but they depend on
> community feedback to gauge if an official release is ready to be
> made.)
>
> The release artefacts we are voting on are available here:
>
> https://dist.apache.org/repos/dist/dev/couchdb/source/3.2.0/rc.1/
>
> There, you will find a tarball, a GPG signature, and SHA256/SHA512 checksums.
>
> Please follow the test procedure here:
>
> 
> https://cwiki.apache.org/confluence/display/COUCHDB/Testing+a+Source+Release
>
> Please remember that "RC1" is an annotation. If the vote passes, these
> artefacts will be released as Apache CouchDB 3.2.0.
>
> Please cast your votes now.
>
> Thanks,
> -Nick

-1

But with Jan and Nick's help we have a nice little patch for this:

https://github.com/apache/couchdb/pull/3770

- FreeBSD 13.0-RELEASE p4 amd64
- elixir 1.12.3
- erlang 24.0.6
- spidermonkey 78
- python3.8.12
- default CC (clang 11.0.1)

After applying the patch I get this error from prometheus tests:

couch_prometheus_e2e_tests:109: deny_prometheus_http...*failed*
in function couch_prometheus_e2e_tests:'-deny_prometheus_http/1-fun-1-'/1 
(test/eunit/couch_prometheus_e2e_tests.erl, line 109)
in call from eunit_test:run_testfun/1 (eunit_test.erl, line 71)
in call from eunit_proc:run_test/1 (eunit_proc.erl, line 522)
in call from eunit_proc:with_timeout/3 (eunit_proc.erl, line 347)
in call from eunit_proc:handle_test/2 (eunit_proc.erl, line 505)
in call from eunit_proc:tests_inorder/3 (eunit_proc.erl, line 447)
in call from eunit_proc:with_timeout/3 (eunit_proc.erl, line 337)
in call from eunit_proc:run_group/2 (eunit_proc.erl, line 561)
**error:{assertEqual,[{module,couch_prometheus_e2e_tests},
  {line,109},
  {expression,"Response"},
  {expected,{error,{conn_failed,{error,econnrefused,
  {value,{error,req_timedout}}]}
  output:<<"">>

couch_prometheus_e2e_tests:80: node_see_updated_metrics...ok
[done in 31.151 s]
  [done in 32.485 s]

A+
Dave

Re: [DISCUSS] API versioning redux

[Dave Cottlehuber]

On Fri, 2 Apr 2021, at 21:07, Ilya Khlopotov wrote:
> Nice list of questions. Couple more from me:
> 
> # global vs per endpoint?
> 
> If we decide for API per endpoint we could different mechanisms to get 
> list of supported versions:
> {
> "couchdb": "Welcome",
> "uuid": "85fb71bf700c17267fef77535820e371",
> "vendor": {
> "name": "The Apache Software Foundation",
> "APIs": {
> "/{db}/{docid}": ["4", "55", "95"]
> }, 
> "version": "1.3.1"
> },
> "APIs": {
> "/{db}/{docid}": ["3", "4", "55"]
> }, 
> "version": "1.3.1"
> }
> ```

Won't all our client ecosystem will need to be updated to accommodate this 
versioning / detection? If so, this should be a simple call, where an API 
returns its capabilities early on, and can adjust its settings accordingly.

We already have `GET / {features: "reshard", ...}`  and many clients keep 
enough state to be able to do a GET /, and make smart decisions from there. 
Would that work?

> # return warnings
> 
> - there is an expired IETF draft  
> https://tools.ietf.org/id/draft-cedik-http-warning-02.html which 
> proposes a convention how to inject warnings into JSON response
> - there is a standard Warning header 
> https://tools.ietf.org/html/rfc7234#section-5.5.7
>   - Warning: 299 api.couchdb.db.doc "Deprecated API: Use v4 instead."
>   - vendors could extend it to look like:
> - Warning: 299 api.couchdb.db.doc "Deprecated API: Use v4 instead.  
> Old v3 API maintained until 2015-06-02"

The supported API endpoints will be dependent on what people run on their 
servers. Rumours of 1.6 and even 1.3 are still out there... we should just put 
this in release notes and roll with it.

What do Large Enterprises see around client versioning and deprecations in 
other cloud businesses? It can't be much fun.

A+
Dave

Re: [ANNOUNCE] Bessenyei Balázs Donát elected as CouchDB committer

[Dave Cottlehuber]

> > On 14. Jan 2021, at 21:48, Robert Newson  wrote:
> > 
> > Dear community,
> > 
> > I am pleased to announce that the CouchDB Project Management Committee has 
> > elected Bessenyei Balázs Donát as a CouchDB committer.
> > 
> > Apache ID: bessbd
> > 
> > Committers are given a binding vote in certain project decisions, as well 
> > as write access to public project infrastructure.
> > 
> > This election was made in recognition of Donát's commitment to the project. 
> > We mean this in the sense of being loyal to the project and its interests.
> > 
> > Please join me in extending a warm welcome to Donát!
> > 
> > On behalf of the CouchDB PMC,
> > 
> > Robert Newson

Awesome! welcome Donát!

A+
Dave

Re: [DISCUSS] moving email lists to Discourse

[Dave Cottlehuber]

On Fri, 13 Mar 2020, at 14:35, Naomi Slater wrote:
> apparently GitHub has discussions now. it's still in beta, but you can 
> specifically request it if you want it if you contact support, I think
> 
> e.g., https://github.com/zeit/next.js/discussions 
> 

interesting.

> I'm interested to know what we think about this and how this 
> might/could fit into our plans for user support, discussion, etc.
> 
> > On 13 Mar 2020, at 00:41, Arturo GARCIA-VARGAS  wrote:
> > 
> > I'm sure Discourse is a fantastic thing (never used it!) but for us 
> > dinosaurs that still use Email it would be a bad move.
> > 
> > Plain text rulez

I concur.

My 2c is that I have become a unix greybeard in habit, if not physical
attributes. I feel that neither slack nor discourse facilitate being
involved in multiple communities concurrently, they are actively hostile to
it. I spent significantly less time in discourse/slack vs irc/email
communities.

The rust discourse, and others that I follow, truncate outbound emails,
and also limit the numbers of outbound messages, effectively making it
not really email, and forcing you to browse the site. This is significantly
slower than churning through a stash of emails to catch up.

That said, user convenience trumps developer satisfaction. If the flock
is moving off mailing lists, then the shepherd should follow.

A+
Dave

Re: native encryption for couchdb 4.0?

[Dave Cottlehuber]

On Thu, 12 Mar 2020, at 17:35, Robert Samuel Newson wrote:
> Hi,
> 
> Yes, platform independent, it's not custom C work, just calls into the 
> existing crypto module.
> 
> Invisible at the API layer, it's all about the protection of data at 
> rest within FDB.

Hey Bob,

Quietly excited about this - I could use this already - I've had horrible
work-arounds in the past to have encrypted .couch backups.

A+
Dave

Re: [VOTE] Release Apache CouchDB 3.0.0 (-rc3)

[Dave Cottlehuber]

> > On 20 Feb 2020, at 00:16, Joan Touzet  wrote:
> > 
> > Dear community,
> > 
> > I would like to propose that we release Apache CouchDB 3.0.0.

+1

- sigs & sha OK
- gmake check
- FreeBSD 13.0-CURRENT amd64
- SM185 & SM60
- OTP 22.2.6

NB both SpiderMonkeys ran for hours in a loop. No issues.

I'll give the aaarch64 a kick this evening just for funsies.

A+
Dave

Re: [ANNOUNCE] Jonathan Hall joins the PMC

[Dave Cottlehuber]

On Mon, 10 Feb 2020, at 19:28, Jonathan Hall wrote:
> Thanks everyone for the warm (re)welcome!
> 
> Jonathan

Long overdue! Welcome again :-)

Dave

Re: [VOTE] Release Apache CouchDB 3.0.0 (-rc1)

[Dave Cottlehuber]

On Fri, 14 Feb 2020, at 20:13, Dave Cottlehuber wrote:
> > Please cast your votes now.
> 
> +1
> 
> - FreeBSD 13.0-CURRENT amd64
> - SM185 & SM60 
> - OTP 22.2.6

also a very excited double-plus-one for ... drumroll ...

FreeBSD 13.0-CURRENT aarch64 / armv8 < aw
- SM60 with very latest patches 60.9.0_1
- OTP 21.3.8.11

Finished in 58.4 seconds
301 tests, 0 failures, 24 excluded

Randomized with seed 566866
gmake[1]: Leaving directory '/tmp/apache-couchdb-3.0.0'
root@a01:/tmp/apache-couchdb-3.0.0 # uname -a
FreeBSD a01 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r357847: Thu Feb 13 04:15:31 
UTC 2020 
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC  arm64
root@a01:/tmp/apache-couchdb-3.0.0 # 

I've left both of these running in a loop, but so far I've had over an hour 
without any issue. Very very excited.

A+
Dave
—
   sent from my Couch

Re: [VOTE] Release Apache CouchDB 3.0.0 (-rc1)

[Dave Cottlehuber]

On Mon, 10 Feb 2020, at 16:33, Joan Touzet wrote:
> Dear community,
> 
> I would like to propose that we release Apache CouchDB 3.0.0.
> 
> Candidate release notes:
> 
>  https://docs.couchdb.org/en/latest/whatsnew/3.0.html
> 
> We encourage the whole community to download and test these release 
> artefacts so that any critical issues can be resolved before the release 
> is made. Everyone is free to vote on this release, so dig right in! 
> (Only PMC members have binding votes, but they depend on community 
> feedback to gauge if an official release is ready to be made.)
> 
> The release artefacts we are voting on are available here:
> 
>  https://dist.apache.org/repos/dist/dev/couchdb/source/3.0.0/rc.1
> 
> There, you will find a tarball, a GPG signature, and SHA256/SHA512 
> checksums.
> 
> Please follow the test procedure here:
> 
>  
> https://cwiki.apache.org/confluence/display/COUCHDB/Testing+a+Source+Release
> 
> Please remember that "RC1" is an annotation. If the vote passes, these 
> artefacts will be released as Apache CouchDB 3.0.0.
> 
> Please cast your votes now.

+1

- FreeBSD 13.0-CURRENT amd64
- SM185 & SM60 
- OTP 22.2.6


Also huge shout-out to Joan in recognition of the significant amount of time 
which you've put in here not just for this release but also the huge CI
refactoring over the last months. It's incredibly incredible!

I do get a build failure on FreeBSD 13.0-CURRENT aarch64 (armv8) for couchjs. 
Only SM60 is available on arm-flavoured FreeBSD so I had high hopes :-( 
https://freshports.org/lang/spidermonkey60 and there's a commit which I don't 
yet have which *might* help

12 Jan 2020 22:34:38
Original commit files touched by this commit  60.9.0_1
Revision:522842

Add simple patch to fix undefined symbol problems when trying to build
gjs with this spidermonkey version.

taken from  https://bugzilla.mozilla.org/show_bug.cgi?id=1426865

Given that I would be the only user for this release on this combo, let's not 
block it. But if somebody has suggestions on what to do, I'm all ears, and I'll 
try with these patches over the weekend.

ld: error: undefined symbol: void 
js::UnsafeTraceManuallyBarrieredEdge(JSTracer*, JS::Value*, char 
const*)
...


In file included from priv/couch_js/60/main.cpp:27:
In file included from /usr/local/include/mozjs-60/js/Wrapper.h:12:
/usr/local/include/mozjs-60/js/Proxy.h:206:43: warning: offset of on 
non-standard-layout type 'js::BaseProxyHandler' [-Winvalid-offsetof]
  static size_t offsetOfFamily() { return offsetof(BaseProxyHandler, mFamily); }
  ^  ~~~
/usr/include/stddef.h:75:31: note: expanded from macro 'offsetof'
#define offsetof(type, field)   __offsetof(type, field)
^~
/usr/include/sys/cdefs.h:476:34: note: expanded from macro '__offsetof'
#define __offsetof(type, field)  __builtin_offsetof(type, field)
 ^~
1 warning generated.
Compiling priv/couch_js/60/utf8.cpp
In file included from priv/couch_js/60/utf8.cpp:16:
In file included from /usr/local/include/mozjs-60/js/Wrapper.h:12:
/usr/local/include/mozjs-60/js/Proxy.h:206:43: warning: offset of on 
non-standard-layout type 'js::BaseProxyHandler' [-Winvalid-offsetof]
  static size_t offsetOfFamily() { return offsetof(BaseProxyHandler, mFamily); }
  ^  ~~~
/usr/include/stddef.h:75:31: note: expanded from macro 'offsetof'
#define offsetof(type, field)   __offsetof(type, field)
^~
/usr/include/sys/cdefs.h:476:34: note: expanded from macro '__offsetof'
#define __offsetof(type, field)  __builtin_offsetof(type, field)
 ^~
1 warning generated.
Compiling priv/couch_js/60/util.cpp
Compiling priv/icu_driver/couch_icu_driver.c
Compiling priv/couch_ejson_compare/couch_ejson_compare.c
ld: error: undefined symbol: void 
js::UnsafeTraceManuallyBarrieredEdge(JSTracer*, JS::Value*, char 
const*)
>>> referenced by Value.h:1230 (/usr/local/include/mozjs-60/js/Value.h:1230)
>>>   
>>> priv/couch_js/60/util.o:(JS::GCPolicy::trace(JSTracer*, 
>>> JS::Value*, char const*))
c++: error: linker command failed with exit code 1 (use -v to see invocation)
ERROR: sh(c++ priv/couch_js/60/http.o priv/couch_js/60/main.o 
priv/couch_js/60/utf8.o priv/couch_js/60/util.o -L/usr/local/lib -std=c++14 
-lmozjs-60 -lm -DHAVE_CURL -lcurl  
-L"/usr/local/lib/erlang/lib/erl_interface-3.11.3/lib" -lerl_interface -lei -o 
priv/couchjs)
failed with return code 1 and the following output:
ld: error: undefined symbol: void 
js::UnsafeTraceManuallyBarrieredEdge(JSTracer*, JS::Value*, char 
const*)
>>> referenced by Value.h:1230 (/usr/local/include/mozjs-60/js/Value.h:1230)
>>>   
>>> priv/couch_js/60/util.o:(JS::GCPolicy::trace(JSTracer*, 
>>> JS::

Re: [PROPOSAL] Drop Erlang 19 support in CouchDB 3.0

[Dave Cottlehuber]

On Thu, 12 Dec 2019, at 01:35, Joan Touzet wrote:
> Hello everyone,
> 
> I'm working this week with Paul Davis on our new Jenkins CI
> infrastructure, which is coming along nicely. One of the changes I'm
> planning to make is that our PR tests will run against only 3 versions
> of Erlang:
> 
> 1. The oldest we support (right now, 19.3.6.latest)
> 2. The version we currently ship with our binary distros & Docker
>(right now, 20.3.8.latest)
> 3. The very latest version we support (right now, 22.2)
> 
> In preparing the containers for CI testing, it's turning out to be very
> difficult to build Erlang 19.* anymore on modern Linuxes. This is
> because they ship with OpenSSL 1.1+, and 19.* cannot build against
> anything newer than OpenSSL 1.0.
> 
> I can jump through a huge number of hoops for this...or we can just drop
> Erlang 19 support for CouchDB 3.0 and require Erlang 20. (Note we
> blacklist a number of versions of Erlang 20.) I would then replace
> 19.3.6.latest with 20.3.8.11 [1].

+1

FWIW RabbitMQ has done the same (21 & 22 only soon), and in FreeBSD
we drop <19 from January, and I expect to be more aggressive on that
in future, in line with what the OTP team have stated.

I would consider going with 21+ only and be done with this.

A+
Dave

Re: [VOTE] Release Apache CouchDB 2.3.1 RC3

[Dave Cottlehuber]

+1 woop woop!

FreeBSD 12.0-RELEASE-p3 amd64 + OTP 21.2.6 custom

- OK sigs and checksums
- OK release
- make check OK**
- fauxton verify is happy

https://upload.wikimedia.org/wikipedia/commons/e/ee/Tall_ship_Christian_Radich_under_sail.jpg
[SHIP IT]

**  so long as I exclude python-black tests due to  C.UTF-8 issues Joan has 
mentioned previously
A+
Dave

Re: [DISCUSS] Attachment support in CouchDB with FDB

[Dave Cottlehuber]

On Thu, 28 Feb 2019, at 13:19, Robert Newson wrote
> Thanks to you both, and I agree. 
> 
> Adam's "I would like to see a basic “native” attachment provider with 
> the limitations described in 2), as well as an “object store” provider 
> targeting the S3 API." is my position/preference too. 

ditto. node local storage works for me, this is the single node case which is 
important to have not just for devs but any small environment.

there is a plethora of clustered file systems waiting to eat your data if 1 
node isnt enough, and while i dont enjoy the s3 api it is widespread with many 
options for using and self hosting.

range queries are useful to me (thanks Bob!) but if its a deal killer I'd  find 
a workaround, probably a proxy http server.

random thought - if we stored in fdb a url as a pointer then whipping up a 
generic proxy would be reasonably easy and could deal with file system and s3 
alike:

file:///usr/local/filesystem
https://my.cdn.com/
s3://aws.clone.com/

this would need to have suitable credentials in couch and some way of knowing 
which credentials go with which db or remote..o0O

in terms of storing full content say 100s of mb in fdb as Bob's outlined, is 
the main concern handling potentially failed  partial  uploads? like our 
current b tree lost space? or are there other issues as well?

if so, one could imagine using a temporary key while receiving chunks, and only 
on completion moving those into the correct store?

A+
Dave

Re: [VOTE] Release Apache CouchDB 2.3.1 RC2

[Dave Cottlehuber]

On Mon, 25 Feb 2019, at 10:56, Dave Cottlehuber wrote:
> On Thu, 21 Feb 2019, at 06:27, Jan Lehnardt wrote:
> 
> FreeBSD 12.0-RELEASE-p3 amd64 + OTP 21.2.6 custom
> 
> - OK sigs and checksums
> - OK release
> - fauxton verify is happy
> - make check fails with the C.UTF-8 issues Joan has mentioned previously
> 
> belated +1 from me
> 
> BTW the port will be a bit delayed this time as I need to bump OTP 
> version and that usually has a bit of ports tree shakeout. My patch for 
> that is https://reviews.freebsd.org/D18820 

I forgot to mention that the tarball has the annoying -RC2 suffix in filenames, 
which makes the downstream packaging diffs fiddly. I have that unfinished PR 
https://github.com/apache/couchdb/pull/1927 hopefully to fix that for next time.

A+
Dave

Re: [VOTE] Release Apache CouchDB 2.3.1 RC2

[Dave Cottlehuber]

On Thu, 21 Feb 2019, at 06:27, Jan Lehnardt wrote:

FreeBSD 12.0-RELEASE-p3 amd64 + OTP 21.2.6 custom

- OK sigs and checksums
- OK release
- fauxton verify is happy
- make check fails with the C.UTF-8 issues Joan has mentioned previously

belated +1 from me

BTW the port will be a bit delayed this time as I need to bump OTP version and 
that usually has a bit of ports tree shakeout. My patch for that is 
https://reviews.freebsd.org/D18820 

A+
Dave

Re: [DISCUSS] FoundationDB is network available with no security?

[Dave Cottlehuber]

On Fri, 25 Jan 2019, at 11:18, Michael Fair wrote:
> I see the main differences are:
> 1) if I don't turn on clustering, because i'm single node, the only network
> way into Couch data is via the HTTP layer (at least so I would assume)
> 2) if I do turn on clustering, and I manually connect in to the cluster, I
> haven't been given tools in every scripting language to directly query and
> rewrite the entire dataset.  There's still a lot of internal workings I
> need to understand.

true; bear in mind that couchdb will also have a couch->fdb k/v layer so
it's still not going to be quite as transparent as that.

> With the FDB approach, as a single machine instance, I seem to have no
> choice but to allow every program/script on my machine access to the
> backend of the Couch data.  File level user privileges can't apply, all
> security to the underlying backend data becomes "was the source IP
> 127.0.0.1" or more generally "did the connection come from the right IP
> address".  I am certainly going to find that very useful for my own
> "explorations" to poke around the insides, but it just feels like a step
> backward securitywise.

I agree.
 
> I'm confident the issue will be addressed somehow, and perhaps the TLS
> stuff is all that's really required, but I would think it's really
> important for a server to be able to specify what/who its legitimate peers
> are.  I think this is definitely going to become more of an issue as these
> kinds of decentralized services mature more.
> t
> It'd be awesome if FDB had the option to be/do something like a SQLite
> library or work over a spawned PIPE or something to lock it down so only
> the Couch server instance that launched it could use it...

TLS and TCP are non-negligable overheads, but this may not matter much in
practise. This is what I was thinking of with UNIX domain sockets. So I asked:

https://forums.foundationdb.org/t/feature-request-support-unix-domain-sockets-for-client-local-server-access/1071

A+
Dave

Re: [DISCUSS] Rebase CouchDB on top of FoundationDB

[Dave Cottlehuber]

On Fri, 25 Jan 2019, at 09:58, Robert Samuel Newson wrote:
>

Thanks for sharing this Bob, and also thanks everybody who shared their
thoughts too.

I'm super excited, partly because we get to keep all our Couchy
goodness, and also that FDB brings some really interesting operational
capabilities to the table that normally you spend a decade trying to
build from scratch. The level of testing that has gone into FDB is
astounding[1].

Things like seamless data migration, expanding storage and rebalancing
shards and nodes, as anybody who's dealt with large or long-lived
couchdb clusters knows are Hard Problems today.

There's clearly a lot of work to be done -- it's early days -- and it
changes a lot of non-visible things like packaging, dependencies,
cross-platform support, and a markedly different operations model -- but
I'm most excited about the opportunities here at the storage layer for
us.

Regarding handling larger k/v items than what fdb can handle, is covered
in the forums already[2] and is similar to how we'd query multiple docs
from a couchdb view today using an array-based complex/compound key:

[0, ..] would give you all the docs in that view under key 0

except that in FDB that query would happen for a single couchdb doc, and
returning a range query to achieve that. Similar to multiple docs, there
are some traps around managing that in an atomic fashion at the higher
layer.

I'm sure there are many more things like this we'll need to wrap our
heads around!

Especial thanks to the dual-hat-wearing IBM folk who have engaged with
the community so early in the process -- basically at the napkin
stage[3].

[1]: https://www.youtube.com/watch?v=4fFDFbi3toc
[2]: 
https://forums.foundationdb.org/t/intent-roadmap-to-handle-larger-value-sizes/126
[3]: https://www.computerhistory.org/atchm/the-two-napkin-protocol/ the
famous napkin where BGP, the modern internet's backbone routing
protocol, was described.

A+
Dave

Re: [DISCUSS] FoundationDB is network available with no security?

[Dave Cottlehuber]

On Fri, 25 Jan 2019, at 08:31, Michael Fair wrote:
> In the spirit of discussing any potentially really serious drawbacks, I was
> reading through the FoundationDB documents when I came across this:
> 
> Not a security boundary
> 
> Anyone who can connect to a FoundationDB cluster can read and write every
> key in the database. There is no user-level access control. External
> protections must be put into place to protect your database.
> 
> And this StackOverflow question seems to confirm:
> https://stackoverflow.com/questions/51070230/foundationdb-authentication
> 
> Umm, so what's the expectation here?
> 
> What gets me is that it's also a network server that "accepts" inbound
> connections and they know this already... So if exposed on a public ip
> address (making some site-to-site redundancy configurations easier), the
> entire planet automagically has access to read/write to the entire
> database...  To which I think the answer is: VPNs, Firewalls, and "Don't do
> that, it hurts"

Absolutely.

> Which I think makes Couch a lot more complicated and less secure than it
> is...
> 
> It sounds like the result of this is "any user on any Couch node or any FDB
> node can rewrite the entire FDB database", and that's assuming the
> machine's firewall is configured to restrict access to the relevant IP/PORT
> pairs by source address (otherwise the implication becomes anyone who can
> connect).
> 
> I saw in the recent commits for the latest version a bunch of support for
> TLS, which seems to be echoed in the comment "use the mutual TLS support if
> you want to run a cluster in an untrusted network"...  Will a Couch cluster
> also be required to create/maintain/manage the required cert files and
> configuration?
>
> Or is there some extra magic I'm not seeing somewhere that could prevent
> what seems like a 'local attacker' from maliciously wiping of the entire
> keystore?
> 
> I like being able to just install CouchDB on a laptop and use the web UI to
> secure it up a bit; this seems to risk opening up access directly to the
> keystore...
> 
> Questions/Comments?
> 
> Thanks,
> Mike

Security is, as Shrek would say, like an onion. I think the FDB approach is not 
really very different to clustered Couch today, except that the clustering 
layer is visibly separate instead of "just another impenetrable erlang layer". 
You'll still have the 127.0.0.1 loopback connection needing to be secured, on 
your laptop or elsewhere.

Inside couchdb we have a btree module which does the dirty work of writing 
chunks to files, and a layer on top of that which reads and writes documents 
through that layer.
If you bypass the couch http layer, (say by getting an erlang remote shell 
because you didn't secure that and somebody's on in your system) then you can 
write directly through to the document layer, or the db layer. I happily use 
this for debugging, it's very handy.

Locking down ports and using separate / encrypted networks for cluster data vs 
user traffic, is a normal part of DB & sysadmin life. Securing access to the 
filesystem so you can't have arbitrary users doing r/w to the b-tree directly, 
or wholesale copying the db to an untrusted system.

Having said that, perhaps there's a possibility for FDB to use UNIX domain 
sockets for a local connection?

Currently I use a P2P VPN called zerotier for my (admittedly small) couchdb 
cluster, to secure traffic. Only those 3 instances have access to each other, 
all other connections are mediated through haproxy & couch's http layer.

Previously I've used a "hand-crufted mesh" with spiped, which was rock solid 
but not quite so well suited to the dynamic architectures of today's world.

FDB will need exactly the same sorts of security goop as what we have today.

A+
Dave

Re: [ANNOUNCE] Apache CouchDB 2.3.0 released

[Dave Cottlehuber]

On Fri, 7 Dec 2018, at 07:08, Joan Touzet wrote:
> FYI at this point, all team-provided binary versions are also available:
> 
> .rpm packages
> .deb packages
> Windows x64 binary download
> macOS binary download
> Docker image (amd64) at apache/couchdb and couchdb
> 
> Community members are still helping with the following:
> 
> snap packages
> .deb packages for aarch64 (ARM 64bit), ppcle64 and s390x
> Docker images for aarch64 (ARM 64bit), ppcle64 and s390x
> 
> -Joan

FreeBSD ports support was committed this morning to both trunk & 2018Q4 
branches, and should be available from binary packages in 2-3 days. I took the 
liberty of switching to OTP 21 as the default Erlang now that we support it.

A+
Dave

Re: [VOTE] Release Apache CouchDB 2.3.0-RC1

[Dave Cottlehuber]

On Sun, 2 Dec 2018, at 23:49, Joan Touzet wrote:
> Thanks Dave - with your +1, the build passes, though I'll wait another
> 36-48 hours before calling it. Would like some of our Cloudant friends
> to chime in ;)
> 
> > We have -RC1 in all the couchdb-related deps (fabric, global_changes
> > etc) does this matter? I thought we squashed that in 2.1 or 2.2
> > already, and the tarball only needed to be renamed?
> > 
> > apache-couchdb-2.3.0> l rel/couchdb/lib/
> > total 0
> > drwxr-xr-x  4 dch  wheel   128B Dec  2 21:53 asn1-5.0.7/
> > drwxr-xr-x  4 dch  wheel   128B Dec  2 21:53 b64url-1.0.1/
> > drwxr-xr-x  3 dch  wheel64B Dec  2 21:53 bear-0.8.1-9-g008f48a/
> > drwxr-xr-x  5 dch  wheel   192B Dec  2 21:53 chttpd-2.3.0-RC1/
> > drwxr-xr-x  3 dch  wheel64B Dec  2 21:53 compiler-7.2.6/
> > drwxr-xr-x  3 dch  wheel64B Dec  2 21:53 config-2.1.4/
> > drwxr-xr-x  3 dch  wheel64B Dec  2 21:53 couch_epi-2.3.0-RC1/
> > drwxr-xr-x  3 dch  wheel64B Dec  2 21:53 couch_event-2.3.0-RC1/
> > ...
> > 
> > IMO it's not worth re-rolling the release for this.
> 
> Yeah, I thought we fixed this in 2.1.2/2.2.0 as well. I'm surprised
> that it built like this. If you can look into it, and it's an easy
> fix, I'm happy to push an -RC2 with the fix...or we can leave it like
> this for 2.3.0 and push a fix for 2.3.1/2.4.0. I also don't think it's
> worth re-rolling the release just for this minor thing.
> 
> -Joan

TLDR the issue comes from `{vsn, git}` in the `.app.src` files, which is then 
propagated into the tarball. Normally, rebar does this, but we do it in 
build-aux/couchdb-build-release.sh, without re-using the variables created in 
the Makefile. I'll throw a patch on github for this.

A+
Dave

Re: [VOTE] Release Apache CouchDB 2.3.0-RC1

[Dave Cottlehuber]

On Thu, 29 Nov 2018, at 20:22, Joan Touzet wrote:
> Dear community,
> 
> I would like to release Apache CouchDB 2.3.0-RC1.
> 
> Changes since last round:
> 
>  * https://github.com/apache/couchdb/compare/2.2.0...2.3.0-RC1
> 
> Candidate release notes:
> 
>  * http://docs.couchdb.org/en/latest/whatsnew/2.3.html
> 
> We encourage the whole community to download and test these release 
> artefacts so that any critical issues can be resolved before the release 
> is made. Everyone is free to vote on this release, so dig right in!
> 
> The release artefacts we are voting on are available here:
> 
> 
> https://dist.apache.org/repos/dist/dev/couchdb/source/2.3.0/rc.1/apache-couchdb-2.3.0-RC1.tar.gz
> 
> https://dist.apache.org/repos/dist/dev/couchdb/source/2.3.0/rc.1/apache-couchdb-2.3.0-RC1.tar.gz.asc
> 
> https://dist.apache.org/repos/dist/dev/couchdb/source/2.3.0/rc.1/apache-couchdb-2.3.0-RC1.tar.gz.sha256
> 
> https://dist.apache.org/repos/dist/dev/couchdb/source/2.3.0/rc.1/apache-couchdb-2.3.0-RC1.tar.gz.sha512
> 
> Please follow the test procedure here:
> 
> 
> https://cwiki.apache.org/confluence/display/COUCHDB/Testing+a+Source+Release
> 
> Please remember that "RC1" is an annotation. If the vote passes, these 
> artefacts will be released as Apache CouchDB 2.3.0.
> 
> Please cast your votes now.
> 
> Thanks,
> Joan "we promised and delivered 2 releases a year" Touzet
^^^

+1

- sigs+sha OK
- all tests pass (OMG)
- OTP 21.1.1
- FreeBSD 12.0-RC3 amd64 (sweet releases happening everywhere)

niggle:

We have -RC1 in all the couchdb-related deps (fabric, global_changes etc) does 
this matter? I thought we squashed that in 2.1 or 2.2 already, and the tarball 
only needed to be renamed?

apache-couchdb-2.3.0> l rel/couchdb/lib/
total 0
drwxr-xr-x  4 dch  wheel   128B Dec  2 21:53 asn1-5.0.7/
drwxr-xr-x  4 dch  wheel   128B Dec  2 21:53 b64url-1.0.1/
drwxr-xr-x  3 dch  wheel64B Dec  2 21:53 bear-0.8.1-9-g008f48a/
drwxr-xr-x  5 dch  wheel   192B Dec  2 21:53 chttpd-2.3.0-RC1/
drwxr-xr-x  3 dch  wheel64B Dec  2 21:53 compiler-7.2.6/
drwxr-xr-x  3 dch  wheel64B Dec  2 21:53 config-2.1.4/
drwxr-xr-x  3 dch  wheel64B Dec  2 21:53 couch_epi-2.3.0-RC1/
drwxr-xr-x  3 dch  wheel64B Dec  2 21:53 couch_event-2.3.0-RC1/ ...

IMO it's not worth re-rolling the release for this.

A+
Dave

Re: [VOTE] Release Apache CouchDB 2.3.0-RC1

[Dave Cottlehuber]

On Sun, 2 Dec 2018, at 19:53, Naomi Slater wrote:
> hey folks,
> 
> it's been a while since I tested a release. but here we go

\o/ 

> /private/tmp/couchdb/dist/apache-couchdb-2.3.0/src/couch/priv/couch_js/
> http.c
> /private/tmp/couchdb/dist/apache-couchdb-2.3.0/src/couch/priv/couch_js/
> http.c:18:10:
> fatal error: 'jsapi.h' file not found
> #include 
>  ^
> 1 error generated.
> ERROR: compile failed while processing
> /private/tmp/couchdb/dist/apache-couchdb-2.3.0/src/couch: rebar_abort
> make: *** [couch] Error 1
> 
> so it seems like there's another dependency I don't have. but I can't tell
> just from looking at this error message what is missing
> 
> so I guess I have two questions:
> 
> 1. what do I need to do to get this working?

install spidermonkey 1.8.5. I guess `brew install spidermonkey icu4cx erlang`
should be enough but I don't have a suitable mac to hand. I guess you're using 
homebrew?

> 2. I don't have any opinions re the removal of GNU Autoconf. I'm sure there
> was a reason, etc, etc. but it seems to me that the install experience is
> somewhat worse than the last time I looked at it. without the dependency
> checking in `./configure`, these messages are not a great first run
> experience. is this a known issue?

No but it should be reasonably easy to add those back. The dependencies are
listed in the usual places though.

A+
Dave

Re: FreeBSD Port of CouchDB 2.x

[Dave Cottlehuber]

On Fri, 24 Aug 2018, at 22:29, Dave Cottlehuber wrote:
> Just following up, 2.2.0 is fine with OTP20 and the FreeBSD port should
> be committed next week.

It wasn't quite /next week/ but finally...

https://svnweb.freebsd.org/ports?view=revision&revision=480279

FreeBSD 2.2.0 port for CouchDB has finally landed.

A special thanks to Reshad, who contributed a great deal of this port, 
including a lot of patience while we kept chipping away at getting it just 
right, and the FreeBSD ports team especially  jrm@ and mat@ who kept us on the 
straight and narrow.

A+
Dave

update ibrowse to 4.4.1?

[Dave Cottlehuber]

I need working IPv6 support (for replication) in ibrowse, which is only in 
4.4.1. It's a trivial backport[0] for a single patch, but we have a rather 
bespoke v4.0.1 copy from 2012, not a clone, it's via svn  and it's not friendly 
to rebasing [1]. 

I'm ok to have a crack at this next week, with the end goal of being able to 
rebase future ibrowse releases directly in git, possibly with a minimal 
conversion makefile target.

Any objections to updating it? Has anybody already had a go?

Here's the current non-trivial diff: https://git.io/fA9Ju

Even if you ignore the docs and other build files Bob removed during 4af2d40,  
a number of the genserver states and callbacks have evolved, and the build 
system is now erlang.mk. I have no idea if our  rebar2 will handle that.

If this means we need to tackle bringing our build system up to rebar3 or 
erlang.mk or whatever then I'm happy to plug away on that first.

[0]: https://github.com/cmullaparthi/ibrowse/commit/ce20f97
[1]: I pushed our copy to my skunkwerks/asf branch and github is very annoyed: 
https://github.com/cmullaparthi/ibrowse/compare/v4.0.1...skunkwerks:asf and 
rebase dies in a quiet fire.

A+
Dave
—
  Dave Cottlehuber
  d...@apache.org
  Sent from my Couch

getting back on the Couch

[Dave Cottlehuber]

hey folks,

I've been busy lately -- turns out 3 kids, some ongoing health troubles, and a 
job has left me with less time than I'd hoped for, but I still hope to keep my 
spot on the Couch warm, so to speak.

As I can squeeze in only a handful of hours a week these days, I'm planning to 
prod things on github where I can help things along, get the 2.x release into 
FreeBSD ports, and I'd said I can handle the IP clearance for the proposed 
bcrypt PR assuming we're good with adding another NIF there. If anybody's 
already progressing that, or wants to work with me, please speak up. Progress 
will be slow, but there will be progress eventually.

I'll re-read our committer-related docs to refresh my memory, but don't 
hesitate to remind me if I err in my functional() ways. I'm on IRC during EU 
daytime pretty much always, dch in #couchdb as usual.

A+, Dave
—
  Dave Cottlehuber
  d...@apache.org
  Sent from my Couch

Re: [AMEND OFFICIAL DOCUMENTS] Bylaws revision: HTTP API change notifications

[Dave Cottlehuber]

On Mon, 12 Feb 2018, at 17:39, Joan Touzet wrote:
> Hi everyone,
> 
> I have incorporated minor feedback from Robert Newson and Paul
> Davis.
> 
> https://github.com/apache/couchdb-www/pull/27
> 
> The changes reflect that we do not promise backwards compatibility
> for bugs in the published HTTP API, nor do we promise any sort
> of compatibility for undocumented behaviour (such as the change
> to database sequence values between 1.x and 2.x.)
> 
> It also clarifies that the compatibility promise is only for
> _released_ versions of CouchDB.
> 
> The vote passes, but because of the minor clarifications to the
> PR, I'll leave the PR for another 24 hours before merging.
> 
> -Joan
...
> This is my own +1 vote.
> 
> With Alex and Jan's votes, this may now pass (in ~60 hours); other PMC
> members should speak up now if they have concerns. I would like to
> pass this key change with unanimous consent.
> 
> -Joan

Sorry I managed to be on holiday for this; a belated +1 for moral support.
Thanks Joan.

A+
Dave

Re: [VOTE] Release Apache CouchDB 1.7.1-RC1

[Dave Cottlehuber]

On Fri, 10 Nov 2017, at 22:16, Paul Davis wrote:
> make check all green on OS X 10.12
>

+1

- gpg sig OK
- sha256, sha512 OK

FreeBSD 11.1R amd64 & OTP 19
FreeBSD 12.0-CURRENT amd64

verify install is OK

- minor error in /bin/couchdb wrt compatible shell script syntax, effect
  is cosmetic & can be fixed later- some reproducible errors reported during 
`make check-js`
TLDR same as it ever was

Re: [VOTE] Release Apache CouchDB 2.1.1-RC2

[Dave Cottlehuber]

EEEOn Wed, 1 Nov 2017, at 23:21, Joan Touzet wrote:
> Dear community,
> 
> I would like to release Apache CouchDB 2.1.1-RC2.

Thanks Joan,

+1

- gpg sig ok
- sha256 & sha512 ok
- make check is happy

FreeBSD 12.0-CURRENT amd64
OTP 19.3.6

🚀🚀🚀

A+
Dave

Re: [VOTE] Release Apache CouchDB 1.7.0-RC1

[Dave Cottlehuber]

On Sat, 4 Nov 2017, at 22:55, Andy Wenk wrote:
> I get a 404 whne trying to GET the sha256 and sha512 files:

I should have mentioned that in my reply, sorry Andy.

> >wget 
> > https://dist.apache.org/repos/dist/dev/couchdb/source/1.7.0/rc.1/apache-couchdb-1.7.0.tar.gz
> >wget 
> > https://dist.apache.org/repos/dist/dev/couchdb/source/1.7.0/rc.1/apache-couchdb-1.7.0.tar.gz.asc
> >wget 
> > https://dist.apache.org/repos/dist/dev/couchdb/source/1.7.0/rc.1/apache-couchdb-1.7.0.tar.gz.tar.gz.sha256
> >wget 
> > https://dist.apache.org/repos/dist/dev/couchdb/source/1.7.0/rc.1/apache-couchdb-1.7.0.tar.gz.tar.gz.sha512

This was a subtle trick to fool mere mortals...  the amended URLs are:

> >wget 
> > https://dist.apache.org/repos/dist/dev/couchdb/source/1.7.0/rc.1/apache-couchdb-1.7.0.tar.gz.sha256
> >wget 
> > https://dist.apache.org/repos/dist/dev/couchdb/source/1.7.0/rc.1/apache-couchdb-1.7.0.tar.gz.sha512

svn never lies.
https://dist.apache.org/repos/dist/dev/couchdb/source/1.7.0/rc.1/

A+
Dave

Re: [VOTE] Release Apache CouchDB 1.7.0-RC1

[Dave Cottlehuber]

On Wed, 1 Nov 2017, at 21:30, Jan Lehnardt wrote:
> Dear community,
> 
> I would like to release Apache CouchDB CouchDB 1.7.0-RC1.>
> Special thanks to Alexander “Kxepal” Shorin for putting in the bulk of
> the work making this long-awaited release happen.

👏

+1

gpg sig, sha512 & sha256 match

- Windows 7 x64 (using 32-bit OTP & couch)
- OTP R15B03-1 x86
- much angst and grief

- FreeBSD 12.0-CURRENT amd64
- OTP 19.3.6
also FreeBSD 11.1R amd64 + i386
also FreeBSD 10.4R amd64 + i386

Re: [VOTE] Release Apache CouchDB 2.1.1-RC2

[Dave Cottlehuber]

On Thu, 2 Nov 2017, at 22:54, Dave Cottlehuber wrote:
> On Wed, 1 Nov 2017, at 23:21, Joan Touzet wrote:
> > Dear community,
> > 
> > I would like to release Apache CouchDB 2.1.1-RC2.
> > 
> > Changes since 2.1.1-RC1 are here:
> > 
> > https://github.com/apache/couchdb/compare/2.1.1-RC1...2.1.1-RC2
> > 
> > Human-readable change notes are here:
> > 
> > http://docs.couchdb.org/en/latest/whatsnew/2.1.html#version-2-1-1
> > 
> > We encourage the whole community to download and test these release
> > artefacts so that any critical issues can be resolved before the release
> > is made. Everyone is free to vote on this release, so dig right in!
> > 
> > The release artefacts we are voting on are available here:
> > 
> > wget
> > 
> > https://dist.apache.org/repos/dist/dev/couchdb/source/2.1.1/rc.2/apache-couchdb-2.1.1-RC2.tar.gz
> > wget
> > 
> > https://dist.apache.org/repos/dist/dev/couchdb/source/2.1.1/rc.2/apache-couchdb-2.1.1-RC2.tar.gz.asc
> > wget
> > 
> > https://dist.apache.org/repos/dist/dev/couchdb/source/2.1.1/rc.2/apache-couchdb-2.1.1-RC2.tar.gz.sha256
> > wget
> > 
> > https://dist.apache.org/repos/dist/dev/couchdb/source/2.1.1/rc.2/apache-couchdb-2.1.1-RC2.tar.gz.sha512
> 
> Thanks Joan!
> 
> - sha256 is fine
> - gpg sig is fine
> - sha512 is not,  I see 143 bytes of garbage & not ascii-fied
> hexadecimal

FYI I've checked with Joan separately, & updated the SHA512 sig.

Our SHA512s match, it's just the mime-type properties in svn needed
tweaking.  Just grab
https://dist.apache.org/repos/dist/dev/couchdb/source/2.1.1/rc.2/apache-couchdb-2.1.1-RC2.tar.gz.sha512
again. Or unzip your existing one (really).
svn propset svn:mime-type text/plain *.sha512

A+
Dave

Re: [VOTE] Release Apache CouchDB 2.1.1-RC2

[Dave Cottlehuber]

On Wed, 1 Nov 2017, at 23:21, Joan Touzet wrote:
> Dear community,
> 
> I would like to release Apache CouchDB 2.1.1-RC2.
> 
> Changes since 2.1.1-RC1 are here:
> 
> https://github.com/apache/couchdb/compare/2.1.1-RC1...2.1.1-RC2
> 
> Human-readable change notes are here:
> 
> http://docs.couchdb.org/en/latest/whatsnew/2.1.html#version-2-1-1
> 
> We encourage the whole community to download and test these release
> artefacts so that any critical issues can be resolved before the release
> is made. Everyone is free to vote on this release, so dig right in!
> 
> The release artefacts we are voting on are available here:
> 
> wget
> 
> https://dist.apache.org/repos/dist/dev/couchdb/source/2.1.1/rc.2/apache-couchdb-2.1.1-RC2.tar.gz
> wget
> 
> https://dist.apache.org/repos/dist/dev/couchdb/source/2.1.1/rc.2/apache-couchdb-2.1.1-RC2.tar.gz.asc
> wget
> 
> https://dist.apache.org/repos/dist/dev/couchdb/source/2.1.1/rc.2/apache-couchdb-2.1.1-RC2.tar.gz.sha256
> wget
> 
> https://dist.apache.org/repos/dist/dev/couchdb/source/2.1.1/rc.2/apache-couchdb-2.1.1-RC2.tar.gz.sha512

Thanks Joan!

- sha256 is fine
- gpg sig is fine
- sha512 is not,  I see 143 bytes of garbage & not ascii-fied
hexadecimal

SHA256 (apache-couchdb-2.1.1-RC2.tar.gz) =
44b15b96e4d009fd86e6fa3076c58abe9ca59d7e01b19f5c3f5d6ffa4c748aa8
SHA512 (apache-couchdb-2.1.1-RC2.tar.gz) =
02e642194916bb6bda289aa03df612f6a1ea542b8f9edbb7578362352f48e90e78aac8ade6d3186b593dc10e3b0f0f42a3c2d0b0767dc6568602d71805d7e28d

NB - the gpg sig verifies  after `curl
http://apache.org/dist/couchdb/KEYS | gpg --import -` which is out of
step with our docs.

I've tweaked the wiki
https://cwiki.apache.org/confluence/display/COUCHDB/Testing+a+Source+Release
to include sha256 + sha512 instead of md5 + sha1, and updated the gpg
key fetching step.

Given gpg + sha256 matches, I'm OK for you re-confirming and uploading
your sha512 if you feel that's appropriate.

Rest will come later, along with my actual vote.

A+
Dave

Re: [PROPOSAL] Drop PDF / texinfo documentation builds

[Dave Cottlehuber]

On Sat, 18 Mar 2017, at 05:55, Joan Touzet wrote:
> Hi everyone,
> 
> I'd like to propose dropping the PDF and texinfo targets from our

+1 send them to the dumpster its long overdue.

A+
Dave

Re: [ANNOUNCEMENT] couch-chakra, a CouchDB Query Server Runtime build with ChakraCore

[Dave Cottlehuber]

> > While it is absolutely possible to link everything into one process,
> > that’s usually not done.
> 
> Actually that's what I tried in the very beginning, writing a NIF to
> wrap the ChackraCore API to Erlang functions. While in theory this
> would be possible it's however heavily discouraged by the Erlang gods
> to write NIFs with non-deterministic timing. So I quickly stepped back
> from the NIF idea and instead implemented couch-chakra.

You might not have read about dirty schedulers[1] which seem to be a
stable
API now, & here's a few links from Steve Vinoski related to NIF handling
[2][3]
and some sample code [4] from Steve and from JLouis [5] using them.

We already have some couchdb NIF code, and if there's a performance gain
it
would be great to ship some more.

A+
Dave

[1]:
https://medium.com/@jlouis666/erlang-dirty-scheduler-overhead-6e1219dcc7#.jgdyewal6
[2]: https://www.youtube.com/watch?v=nw2eIB6bTxY
[3]:
https://github.com/vinoski/bitwise/blob/master/vinoski-schedulers.pdf
[4]: https://github.com/vinoski/bitwise
[5]: https://github.com/jlouis/enacl

Re: [ANNOUNCEMENT] couch-chakra, a CouchDB Query Server Runtime build with ChakraCore

[Dave Cottlehuber]

On Tue, 24 Jan 2017, at 18:24, Daniel Munch wrote:
> Thanks Jan for clearing things up, I couldn't have answered better
> myself! And thanks everybody else for the feedback so far.
> 
> >> That clears it up, One more question if I may. In use would this
> >> QueryServer replacement module be an adjacent process to the CouchDB
> >> process, or is there some linking fu to make CouchDB and CouchChakra one
> >> process?
> >
> > I haven’t looked to closely, but how I understand it, this is a separate
> > process. Just like it with CouchDB today (you have a beam[.smp] process
> > and zero or more couchjs processes).
> 
> It currently takes exactly the same approach as couchjs - one beam
> process, zero or more couchjs processes, that's why I called it a
> drop-in replacement. In theory you could switch out couchjs by
> couch-chakra and everything should work like before.
> 
> > While it is absolutely possible to link everything into one process,
> > that’s usually not done.
> 
> Actually that's what I tried in the very beginning, writing a NIF to
> wrap the ChackraCore API to Erlang functions. While in theory this
> would be possible it's however heavily discouraged by the Erlang gods
> to write NIFs with non-deterministic timing. So I quickly stepped back
> from the NIF idea and instead implemented couch-chakra.
> 
> Also, like Garren said in a mail before, there has been a couple of
> attempts to redesign the Query Server Protocol and the process model
> for the javascript query server. It looks as if there were different
> opinions on this, and it also looks like it could become a lot of
> work. Personally I'd love to see a binary communication protocol
> between couchdb and the query server and thought that BERT and
> BERT-RPC [1] might be a viable option. I'd also love to exploit the
> rental threading model of ChakraCore like it is explained in the
> article on how Chakra is used in DocumentDB [2]: "In other words, a
> runtime only operates on one thread at a time, but its thread affinity
> is free to change from time to time."
> 
> Add libuv to the sauce and we might win the next buzzword-bingo
> contest with distinction, but that's what this project currently
> represents for me: A playground to explore weird ideas and to have
> some fun hacking on in my free-time.
> 
> Best,
> Daniel

I love this!

In particular Daniel's offered some solutions for finally handling
anonymous functions, which is super awesome and long overdue.
 
Being able to run our test suite with different JS engines would be
really cool, as well as shipping some alternatives.

Serialisation uses a lot of CPU in CouchDB and any experiments or
adventures into finding ways to improve this would be welcome. Currently
we do all of the following:

browser/API (javascript native <->json)
couchdb (json <-> erlang terms)
couchjs ( json <-> javascript native)

I'd love to see some incremental/experimental changes or tests in this
space, as previous attempts got side tracked with discussion rather than
shipped contributions. Providing alternate couchjs builds is relatively
low-impact compared to alternative communication protocols, maybe thats
a good place to start.

A+ 
Dave

Re: Checking for cluster peers using SRV records on startup

[Dave Cottlehuber]

On Fri, 7 Oct 2016, at 02:57, Adam Kocoloski wrote:
> Hi all,
> 
> Lately I’ve been thinking about how to ease the onramp for users to get a
> clustered CouchDB setup running. I think the Kubernetes work shows a lot
> of promise. One of the aspects of that work is the service discovery
> element; each node in a cluster should be able to automatically find its
> peers and connect to them. Kubernetes accomplishes this using SRV
> records; a DNS lookup for a given named service will return the FQDNs of
> all the live members of the “Pet Set”.
> 
> The SRV approach is enough of a standard[1] that I wonder if we ought to
> code for it directly in mem3. It’d eliminate the need for a “sidecar”
> container in Kubernetes deployments and I can imagine that it will prove
> more generally useful. The idea would be for mem3 to check if the CouchDB
> node is running in distributed node, and if it is, fire off a DNS lookup
> on the domain name, then attempt to connect with any other targets that
> are included in the record set in the DNS response.
> 
> What do you think? If no one objects I’ll file a JIRA and see what we
> come up with.

belated +1 for _SRV records, +1000 for combining that with MDNS also for
initial cluster setup. There are a number of erlang libraries already to
help with this - below.

the key issue with _SRV records is that, just like A records and CNAMEs
is that you need to put them manually into DNS already. I am not sure
this makes discovery easier...

Something like mdns provides a multicast DNS lookup service, and nails
this problem squarely.

It is the bonjour/rendezvous/zeroconf tech used heavily by Apple
devices, HP for printers etc. super nice. I am using this atm for
service discovery albeit non-erlang stuff. It didnt quite get out of the
RFC stage but its the defacto standard at least for consumer gear.
http://www.zeroconf.org/

https://github.com/shortishly/mdns or
https://github.com/Licenser/erlang-mdns-server | client

Also worth a look is https://github.com/shortishly/haystack with more
docker sauce

Another alternative is zbeacon, http://czmq.zeromq.org/manual:zbeacon ,
also with erlang implementation https://github.com/zeromq/ezmq which
I've only given a passing glance to.

A+
Dave

Re: CouchDB 2.0 as Snap

[Dave Cottlehuber]

> However at present they have a serious limitation wrt storage that is a
> production showstopper - each snap version creates a new copy of
> couchdb, and copies across the data files. I can't confirm yet if this

BTW damjan on IRC pointed out SNAP_COMMON: writable area persistent
across all revisions of the snap at
http://snapcraft.io/docs/reference/env  which if suitable would be
great.

A+
Dave

Re: CouchDB 2.0 as Snap

[Dave Cottlehuber]

> >>> On Mon, Sep 19, 2016 at 4:47 AM, Michael Hall  
> >>> wrote:
> >>> 
> >>> First off, congratulations on the upcoming 2.0 release!
> >>> 
> >>> I would love to see this new version available as a Snap package for
> >>> users of Ubuntu 16.04 LTS, since the archive version will be frozen on

Thanks Michael,

These sound awesome. Snaps are looking great -- especially compared to
the frustration of older debian / centos packaging tools that carry 2
decades of cruft under the hood.

However at present they have a serious limitation wrt storage that is a
production showstopper - each snap version creates a new copy of
couchdb, and copies across the data files. I can't confirm yet if this
is copy-on-write or not which at least would not be (initially) too bad,
or a naive copy that duplicate disk blocks entirely. I suspect the
latter as there is not much choice when it comes to cross-filesystem
compatibility. Either way, if you have reasonably sized couches & viewed
snaps will put you in a situation of needing to clean up old data to
avoid running out of free disk space (e.g. during compaction) due to
data kept in old snaps.

We're not the only database to experience this constraint however and
I'm sure a suitable solution will appear in due course. Go snaps!

A+
Dave

Re: [VOTE] Release Apache CouchDB 2.0.0-rc.1

[Dave Cottlehuber]

src:  sigs, checksums OK
build: OK
fauxton: OK & stunningly beautiful

+1

OS: FreeBSD 11-0.RC3 amd64
erlang: 19.0.1,3
spidermonkey: 1.8.5_2

wrt testing I set up haproxy as well with the supplied config, ran some
big (20GB+ replications) concurrrently, all good -- still running due to
bandwidth constraints. concurrent sharded view builds is simply
fantastic.

As mentioned to Bob on IRC, in ./dev/run the system is accessible not
only overt 127.0.0.1:15984, but 0.0.0.0 i.e. all interfaces & internet
accessible. This should be confirmed by someone else and can be fixed
post-release.

A+
—
  Dave Cottlehuber
  Skunkwerks, GmbH
  http://skunkwerks.at/
  sent from my Couch

Re: Cleaning up the git repo

[Dave Cottlehuber]

On Sat, 16 Jul 2016, at 12:42, Jan Lehnardt wrote:
> Heyall,
>
> in light of 2.0 getting real, I’d like to clean up the git repo.
 
Super! We also need the github mirror cleaned up; IIRC infra@ need to
take care of that on our behalf as it is not automatic last I asked.
 
Dave
 
 

Re: Point release for 1.x.x branch - 1.7.0 ?

[Dave Cottlehuber]

On Tue, 12 Jul 2016, at 11:33, Eugene Pirogov wrote:
> Hi all,
> 
> Current stable release for couchdb is 1.6.1 is almost 2 years old (turns
> in
> september). It supports up to erlang 17.0
> <https://github.com/apache/couchdb/blob/1.6.1/configure.ac#L414>. To
> build
> it using erlang > 17.0, one must either patch the source of 1.6.1 (an
> instance of which can be seen here
> <https://github.com/Homebrew/homebrew-core/blob/master/Formula/couchdb.rb#L249-L378>,
> for example), or build 1.x.x from sources (1.x.x was just ensured to be
> working well with 18.3 and 19.0, see this
> <https://github.com/apache/couchdb/commit/5b9742caaf89bb95bc663110146aa35b16eddb36>
> commit)
> 
> Can we please have a stable 1.x.x release to simplify building couchdb
> against new erlang?:
> 
>- Here are all the changes that would go into release – 1.6.1...1.x.x
><https://github.com/apache/couchdb/compare/1.6.1...1.x.x>
>- If I'm not mistaken, the release would have to be tagged as 1.7.0
>(per
>this
>
> <https://github.com/apache/couchdb/commit/83cf448f0b340a169f547323f8aacddcfd741603>
>commit).
> 
> My motivation for asking this comes from trying to update another recipe
> on
> homebrew, the one for erlang itself. There's an evidence
> <https://github.com/Homebrew/homebrew-core/pull/2279#issuecomment-230648544>
> that updating erlang to 19.0 on OS X will break couchdb 1.6.1
> installation
> for all OS X users.
> 
> Having a new stable release for couchdb would allow to:
> 
>- include updated release in homebrew couchdb recipe,
>- cleanup the couchdb recipe from an aforementioned patch,
>- un-block the 19.0 release of erlang for all OS X homebrew users.
> 
> Please, let me know if for some reason it's impossible to make a release,
> and I will work on some short-term solution.
> 
> -- 
> http://www.gmile.me

We have patches going into FreeBSD & OSX Homebrew for 19.0 support of
1.6.1 atm now with Eugene's efforts. From my side I am OK to shepherd
this through the release process, in & around my couple of weeks holiday
in the start of August.

Question is how this sits with the 2.0 RC that people are working hard
on, I'd not want to interrupt that.

A+
Dave
—
  Dave Cottlehuber
  d...@apache.org
  Sent from my Couch

Re: Adam Kocoloski is now an IBM Fellow

[Dave Cottlehuber]

On Fri, 15 Apr 2016, at 10:50, Jan Lehnardt wrote:
> Hey all,
> 
> our own Adam made IBM Fellow! He’s now one of only 267* individuals
> who’ve been awarded this honour for their contributions to IBM and
> computing in general:
> 
>   http://www.ibm.com/ibm/ideasfromibm/us/ibm_fellows/2016/
> 
> Congratulations Adam, very proud to have you on the team :)
> 
> Best
> Jan
> --

That's spectacular Adam! A very influential and I'm sure well-earned
position.

A+
Dave

CouchDB PPA updates for Ubuntu Wily & Xenial

[Dave Cottlehuber]

Hi,

This is hopefully NEWS-worthy:

I've uploaded the Ubuntu PPA builds for 1.6.1 in the dev PPA, to support
Wily & Xenial (still in alpha but not for long). The main changes are
around correctly implementing systemd-related changes, in particular
couch.uri now lives in /run/ instead of the old-school /var/run/, and we
now have a systemd "unit" controlling CouchDB.

The PPA: https://launchpad.net/~couchdb/+archive/ubuntu/dev/
The source: https://github.com/dch/couchdb-launchpad

If there's any changes or additions people need, please let me know,
otherwise I'll roll this into the stable PPA in about a week.

1.6.1-0ubuntu6ppa2~wily1 

I've done my best to use the new package naming schemes from Ubuntu, but
if those don't look right to you help me out and explain what to use
instead! The intention is that if upstream Debian delivers a CouchDB
1.6.1 package, it should supersede this PPA build unless you pinned it,
and that the base name of the package reflects packaging changes, as
well as rebuilds for each supported Ubuntu release.

Also, some fun:

http://postgradproblems.com/this-artisanal-wood-video-making-fun-of-hipsters-is-hilariously-accurate/

Enjoy your Artisanal Couch.

A+
Dave
—
  Dave Cottlehuber
  Sent from my Couch

Re: Applied for official Docker image

[Dave Cottlehuber]

On Mon, 25 Jan 2016, at 11:44 AM, Alexander Shorin wrote:
> Hi Clemens!
> 
> My own opinion below:
> 
> On Mon, Jan 25, 2016 at 1:32 PM, Clemens Stolle
>  wrote:
> > - Should we use ubuntu and the PPA instead of building from source? The 
> > ubuntu base image is 60MB bigger than debian's.
> 
> We don't provide any PPA builds to use, especially for 2.0, today.
> Ubuntu vs debian - doesn't matter for me.
> 
> > - Building from git branches is not feasible in official images. Are there 
> > tags or pre-release snapshots for 2.0?
> 
> There was developer-preview-2.0 branch for that purpose, but it's
> outdated for now and quickly becomes after each rebase. For current
> state of 2.0 I don't see any point to add special intermediate tags
> for reproduceable builds.
> Also, it may be a bit rushy to include 2.0 image into officials as
> people may accidentally thought that this version is released while
> that's not true.

If it's helpful, we can use the ppa:couchdb/dev for this, and use
couchdb2 as the package name for the interim. Dropping a 2.0 over top of
a 1.x install would be very much against Principle of Least
Astonishment. This approach is very common in FreeBSD ports, for example
with puppet3 and puppet4 to give people a clear distinction.

> > - How does CouchDB handle signals? Currently couchdb doesn’t respond to 
> > SIGTERM. I’m not sure if this is caused by my wrapper shell script.
> 
> SIGTERM works correctly so far.
> 

Worth clarifying here that Erlang/OTP itself is not signal friendly.
There are a number of daemons to help address this, but IIRC all of them
have non-ALv2 taints and/or heavy dependencies.

https://github.com/ShoreTel-Inc/erld
https://github.com/jkingsbery/sighandler
https://github.com/erlware/erlnixify

A competent C programmer could make short work of a GPL-free version of
erld (hint hint) though.

Things a signal handler needs to address:

- rotating logs SIGHUP?
- SIGTERM & friends for shutting down
- terminating BEAM if/when it becomes unresponsive a la heart
- ... others?

The new systemd approach (& presumably docker too) means that the whole
of couchdb runs in a namespace which is then cleaned up. I really like
this, considering how much effort was consumed in getting the original
couchdb script to work correctly.

A+
Dave

Re: Applied for official Docker image

[Dave Cottlehuber]

On Tue, 26 Jan 2016, at 02:19 AM, Eli Stevens (Gmail) wrote:
> On Mon, Jan 25, 2016 at 11:10 AM, Alexander Shorin 
> wrote:
> > On Mon, Jan 25, 2016 at 9:59 PM, Eli Stevens (Gmail)
> >  wrote:
> >> The intent was to hopefully have the build scripts, etc. folded back
> >> into the main repo to make it easier for future releases to have
> >> official packages, but I think that everyone was too focused on core
> >> 2.0 issues to get too involved in packaging (and also enough changed
> >> that it was probably too early to get it right).
> >
> > Hm...nice! Do you have these build scripts? We can put them into our
> > repo now even for 1.6 state. That would be still better than start
> > whole work from scratch and I think we can make these builds official
> > via CI services that will run Ubuntu anyway.
> 
> I don't have the scripts, as the only formal deliverable from earlier
> was a working Ubuntu 12.04 package of 1.6.1 (and we wouldn't have had
> a use for the scripts in any case, as we're not interested in building
> CouchDB ourselves, hence contracting that out to someone who knows
> what they're doing).
>
> I'll let Dave comment about the new work, once we've got a contract
> hammered out, and he's been able to devote some time to the project.
> Again, it might be a bit before that happens.
> 
> Cheers,
> Eli

The scripts are public[1] and we could merge them happily if it makes
sense where they go to. I should explain briefly how these are built, as
this
is relevant.

The repo master branch includes the unpacked couchdb release tarball in
the root, and a /debian/ folder with all the magic pixie dust. On each
new
release (whether of couchdb, updating packaging, or re-packaging for 
a new ubuntu release), do the following:

- spin up a compatible Ubuntu box
- provision with ansible [2]
- bare clone the repo
- check out only the /debian/ packaging directory (patches, dependency
info)
- unpack the new couchdb release
- commit the "changes" to git
- futz around with init scripts, systemd and whatever until couchdb
works

There's no particular reason why this shouldn't work for 2.0, more
detail in
the associated wiki[3]. 

I updated the repo for 1.6.1 and supporting wily + xenial [4], the main
change
is integrating systemd changes and complying with the latest debian
packaging tools, so this is a good base to continue from.

I'm not sure where these scripts would go in our ASF world, but they
should
be kept in step with any releases.

Finally, anybody wishing to contribute to the ppa or the build repo is
welcome
just email me (PPA) or send a PR (build repo).
A+
Dave

[1]: https://github.com/dch/couchdb-launchpad
[2]: https://gist.github.com/dch/86982e187e97a9b23bf5
[3]: https://github.com/dch/couchdb-launchpad/wiki/creating-the-package
[4]: https://launchpad.net/~couchdb/+archive/ubuntu/dev/
[5]: https://launchpad.net/~couchdb/

Re: Windows PR #2

[Dave Cottlehuber]

On Mon, 13 Jul 2015, at 09:56 PM, Joan Touzet wrote:
> I intend to publish it in detail once we have the khash issue
> sorted out, but in short:
> 
> Windows 7 VM
> MSVC 2013 Community Edition
> Erlang 17.5 (didn't want to jump right to 18.x yet)
> Latest Mozilla build chain (for Spidermonkey only)
> ICU latest, binary download only
> 
> For Spidermonkey, I have a minor source tree tweak that allows 
> this build chain to work correctly a) without your crazy
> setup in glazier and b) against MSVC 2013 which was not
> out when 1.8.5 was released. I also build it 64-bit, but
> haven't been able to test it yet (because of khash).

re (a), nice! Not needing the extra shell malarkey is a big help.
One less toolchain :D

I have tried in the past just unpacking the pre-compiled official
erlang release and putting it in the right place beside the source
tarball, which also worked but I'm a little nervous about whether
that is a legitimate approach or not. That could get us down to
just erlang + MSVC which would be a huge step forwards in
simplicity.

A+
Dave

Re: Windows build blocked by khash NIF

[Dave Cottlehuber]

On Sun, 12 Jul 2015, at 09:21 AM, Dave Cottlehuber wrote:
> On Sun, 12 Jul 2015, at 08:35 AM, Joan Touzet wrote:
> > I scoured the mailing lists but was unable to find any sort of patch
> > for this, submitted or not. It's certainly not landed in v18.0.x.
> > 
> > Perhaps Paul is aware of the patch as a starting place at least?

Um I should also say that in the distant past, I built & shipped
modified BEAMs, although that was just to fix up patches that had been
accepted but not released. e.g.
http://people.apache.org/~dch/snapshots/1.1.1/

So I'm not averse to that if we have a patch that's been submitted
upstream and a reasonable expectation of success. In my experience there
are only a handful of people who have built from source on Windows...

—
  Dave Cottlehuber
  d...@apache.org
  Sent from my Couch

Re: Windows PR #2

[Dave Cottlehuber]

On Sun, 12 Jul 2015, at 02:06 AM, Joan Touzet wrote:
> https://github.com/apache/couchdb-couch/pull/69
> 
> Same thing.
> 
> Message to follow with important release-blocking info.

Also +1 super!

What erlang, windows + msvc  setup are you using for this?

A+
Dave

Re: Windows PR #1

[Dave Cottlehuber]

LGTM +1.

On Sun, 12 Jul 2015, at 01:32 AM, Joan Touzet wrote:
> https://github.com/apache/couchdb-b64url/pull/3
> 
> Can I get a +1 before I merge this?
> 
> More Windows build details to come.

Re: Windows build blocked by khash NIF

[Dave Cottlehuber]

On Sun, 12 Jul 2015, at 08:35 AM, Joan Touzet wrote:
> I scoured the mailing lists but was unable to find any sort of patch
> for this, submitted or not. It's certainly not landed in v18.0.x.
> 
> Perhaps Paul is aware of the patch as a starting place at least?
> 
> - Original Message -
> > From: "Adam Kocoloski" 
> > To: dev@couchdb.apache.org, "Joan Touzet" 
> > Sent: Saturday, July 11, 2015 10:08:43 PM
> > Subject: Re: Windows build blocked by khash NIF
> > 
> > There’s a comment in the code where we declare make_hash2() which
> > states
> > 
> > > // There's a pending patch to expose this in the NIF API in newer
> > > Erlangs.
> > 
> > Did that patch ever land?
> > 
> > Adam

Is this unrelated to erlang:phash/2 or erlang:phash2/1,2 ?

It sounds like a thing which if we begged might get into a 17.5.7 or
18.0.3 for example.

A+
Dave

Re: Continuous Integration Redux

[Dave Cottlehuber]

On Sat, 4 Jul 2015, at 12:38 AM, Bastian Krol wrote:
> >> BTW, where could we put this code? I believe the ASF has its own git 
> >> infrastructure, right?
> >
> > You can request couchdb-ci git repo for you. It’ll be mirrored to GitHub 
> > under github.com/apache/couchdb-ci, so you can do PRs as normal(-ish) here: 
> > https://issues.apache.org/jira/servicedesk/customer/portal/1 (set the 
> > mailing list to notificati...@couchdb.apache.org
> 
> For what it's worth, the current work in progress is here: 
> https://github.com/basti1302/couchdb-ci , just in case someone wants to 
> hop on the band wagon :)
> 
> Dominik, Francis, any plans for getting on board?
> 
> Ultimately the code will live at 
> http://git-wip-us.apache.org/repos/asf/couchdb-ci.git, and will be 
> mirrored to https://github.com/apache/couchdb-ci.
> 
> Right now, there is just a rudimentary Ansible script that installs 
> Jenkins and nginx, a Veewee definition for an Ubuntu base box, and a 
> Vagrantfile to test drive the Ansible scripts locally.


Bastian, this sounds great. I'm happy to help out in any way. Also, we
have a couchdb-vm which runs Ubuntu, this might be useful too. See
https://github.com/dch/couchdb-vm for some more notes if that helps.

A+
Dave

[packaging] updated Ubuntu PPA

[Dave Cottlehuber]

Hi folks,

The Ubuntu dev PPA [1] has a minor update to fix an issue reported
privately by Shawn Parrish, that prevents the daemon running correctly
on a minimal Ubuntu 14.04 install. TIL chdir is not built-in...

https://github.com/dch/couchdb-launchpad/commit/c07695b.patch

This covers Trusty and Utopic, if any other version is needed just let
me know. See [2] for package details.

Assuming nobody reports an issue in the next day or so, I'll push the
new builds to the stable PPA [3] for next week.

A+
Dave
—
  Dave Cottlehuber
  d...@apache.org
  Sent from my Couch

[1]: https://launchpad.net/~couchdb/+archive/ubuntu/dev
[2]: https://launchpad.net/~couchdb/+archive/ubuntu/dev/+packages
[3]: https://launchpad.net/~couchdb/+archive/ubuntu/stable

Re: [VOTE] accept Mango contribution from Cloudant IBM

[Dave Cottlehuber]

> It appears the test data uses random/non-existent users, but perhaps somebody 
> can confirm 
> that, e.g. user_docs.py.
>  
> A+
> Dave

Sorry that was unclear. I meant to say that we use test data that has users and 
names and
addresses in it, twitter handles etc.

Can somebody confirm these are actually randomly generated? Some of the domains 
do exist, but
I didn’t find any twitter handles to match.

A+, Dave
— sent from my Couch

Re: [VOTE] accept Mango contribution from Cloudant IBM

[Dave Cottlehuber]

+1 LGTM.

It appears the test data uses random/non-existent users, but perhaps somebody 
can confirm that, e.g. user_docs.py.

A+
Dave

-Original Message-
From: Robert Kowalski 
Reply: dev@couchdb.apache.org >
Date: 18. Dezember 2014 at 23:36:55
To: dev@couchdb.apache.org >
Subject:  [VOTE] accept Mango contribution from Cloudant IBM

> Hi list,
>  
> Cloudant IBM wants to contribute the Mango code, a MongoDB API layer
> for CouchDB to the ASF. This needs a vote of the CouchDB project. The
> tarball is at 
> https://people.apache.org/~robertkowalski/dist/ip-clearance/mango-asf-ip-clearance-2015-12-18.tar.gz
>   
>  
> The SHA is:
>  
> SHA512(mango-asf-ip-clearance-2015-12-18.tar.gz)=
> 809b28fb0ccdab19401fb15a4d0f663ee7a51d2c6cbea4cd5e20621dfac16862f186c0375a3ef485775f78bbc29d88e42f7a6d8abe2d1ef20e96e226298f37ee
>   
>  
>  
> The main repository is located at https://github.com/cloudant/mango -
> I also created the tarball from that source.
>  
> We don't have a match for votings on code contributions in our bylaws,
> so I am chosing Majority Approval by the PMC (that is, 3 +1’s and no
> -1’s) and a 72 hour voting period beginning now (like the BigCouch
> vote in August)
>  
> Best,
> Robert
>  

A+, Dave
— sent from my Couch

Re: Problem installing couchDB because of cygwin dependency

[Dave Cottlehuber]

> Hi CouchDB team,
>  
> I tried installing couchDB from source but it was tough to take care of the
> dependencies, so somehow I found Glazier(https://github.com/dch/glazier)
> to ease my job but It now I am not able to install cygwin. I am getting
> setup.ini not found error. The thing is I tried all the solutions on
> internet regarding this error but none was not able to solve it.
>  
> Any solution to this problem?
>  
> --
> Thanks & Regards,
> Gunjan Soni.
>  
Building couchdb from source on windows is ... tricky. You need to be able to 
build erlang from source as well, and the mozilla spidermonkey javascript 
engine. This requires 4 compilers in all. It’s not for the faint of heart. 

That said, if you need help, you’ll need to provide more details on the 
specific error. I’m by no means an expert on cygwin setup & failures, so I 
suggest starting with 
http://stackoverflow.com/questions/15496333/installing-cygwin-setup-ini-missing-from-http-mirrors-kernel-org
 and working from there. 

A+, Dave
— sent from my Couch

apologies for the pgp-induced garbage from earlier..

Re: Problem installing couchDB because of cygwin dependency

[Dave Cottlehuber]

> Hi CouchDB team,
> =20
> I tried installing couchDB from source but it was tough to take care of=
 the
> dependencies, so somehow I found Glazier(https://github.com/dch/glazier=
)
> to ease my job but It now I am not able to install cygwin. I am getting=

> setup.ini not found error. The thing is I tried all the solutions on
> internet regarding this error but none was not able to solve it.
> =20
> Any solution to this problem=3F
> =20
> --
> Thanks & Regards,
> Gunjan Soni.

Hi Gunjan,

Building couchdb from source on windows is =E2=80=A6 tricky. You need to =
be able to build erlang from source as well, and the mozilla spidermonkey=
 javascript engine. This requires 4 compilers in all. It=E2=80=99s not fo=
r the faint of heart.

That said, if you need help, you=E2=80=99ll need to provide more details =
on the specific error. I=E2=80=99m by no means an expert on cygwin setup =
& failures, so I suggest starting with=C2=A0http://stackoverflow.com/ques=
tions/15496333/installing-cygwin-setup-ini-missing-from-http-mirrors-kern=
el-org=C2=A0and working from there.

A+, Dave
=E2=80=94 sent from my Couch



signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: [ANNOUNCE] Robert Kowalski joins the PMC

[Dave Cottlehuber]

> > On 28 Oct 2014, at 2:56 PM, Andy Wenk wrote:
> >
> > Dear community,
> >
> > I am delighted to announce that Robert Kowalski joins the Apache CouchDB
> > Project Management Committee today.
> >
> > Robert has made outstanding, sustained contributions to the project. This
> > appointment is an official acknowledgement of their position within the
> > community, and our trust in their ability to provide oversight for the
> > project.
> >
> > Everybody, please join me in congratulating Robert!

Welcome Robert,

May you long enjoy the Pointy Hat :-)

A+, Dave
— sent from my Couch

Re: [couchdb] Clarify that "View" is a select field (#271)

[Dave Cottlehuber]

> Hi devs,
>  
> May be remove docs from top level repo for now?

Yes, that is evidently an oversight on my part when moving it to the docs repo. 
Thanks Alex!

A+, Dave
— sent from my Couch

Re: [DISCUSS] Erlang whitespace standards (was: [POLL])

[Dave Cottlehuber]

reindent:
@# requires either vim 7.4, or github.com/vim-erlang/vim-erlang-runtime
@# this should indent the same as emacs erlang major mode or it's a bug
@# add -c ':set runtimepath^=~/v/.vim/bundle/vim-erlang-runtime/' if 
less
vim -E -N --noplugin -u /dev/null -c ':filetype plugin indent on' \
-c ':args src/*.?rl' \
-c 'argdo silent execute "normal gg=G"' \
-c 'update' -c q


muahahahaha "there is still good in you"

allegedly the same as emacs, but I don’t dare try.

A+
Dave
“Join the dark side, together we will rule the galaxy as one."


-Original Message-
From: Alexander Shorin 
Reply: dev@couchdb.apache.org >
Date: 11. Oktober 2014 at 21:37:46
To: dev@couchdb.apache.org >
Subject:  Re: [DISCUSS] Erlang whitespace standards (was: [POLL])

> Fauxton team just announces their JavaScript style guide:
> https://github.com/apache/couchdb-fauxton/pull/91
> I think we should push Erlang one forward too!
>  
> Joan, would you like to continue your great work on it?
> --
> ,,,^..^,,,
>  
>  
> On Tue, Apr 8, 2014 at 2:09 PM, Noah Slater wrote:
> > A good next step would be for someone to move the pertinent info out
> > of this thread and onto the Confluence wiki.
> >
> > One thing we could do is work this guide/standards into our code/PR
> > review procedure. i.e. We make it legit, nay expected, that people
> > assess patches according to the standards, in addition to the normal
> > review process.
> >
> > On 4 April 2014 23:08, Paul Davis wrote:
> >> I definitely agree we should re-format the whole code base any time
> >> soon. Though at some point it'd be a good idea. Hopefully we can find
> >> a lull after the two big forks are merged where we can just have a
> >> commit on each Erlang repo to do the deed while there's no large
> >> outstanding work that'd be super difficult to merge.
> >>
> >> On Fri, Apr 4, 2014 at 9:33 AM, Robert Samuel Newson wrote:
> >>> I appreciate firming up a consensus on indentation styles but I want to 
> >>> be clearly  
> -1 on a codebase-wide reformatting for the foreseeable future. Beyond the 
> merges, we  
> have active branches for older releases, the more reformatting we do, the 
> harder back-  
> and forward-porting becomes. I like the idea of being more consistent for 
> future work  
> and, where code is particularly crufty, refactoring before making a change. 
> The "worst"  
> formatted code in couchdb is generally the oldest, and much of that needs a 
> refactor/rewrite  
> as we get to it.
> >>>
> >>> B.
> >>>
> >>> On 4 Apr 2014, at 14:07, Alexander Shorin wrote:
> >>>
>  Hi Joan and all,
> 
>  I just faced another indention case which left out of scope of the vote:
>  https://gist.github.com/kxepal/2c09fb5348ead90bea04
> 
>  Personally, I'm for 1) variant there.
> 
>  Another interesting case is anonymous function:
>  https://gist.github.com/kxepal/c5480209af9e93a14155
> 
>  I prefer 3) one.
> 
>  What would be your recommendations there about?
> 
>  --
>  ,,,^..^,,,
> 
> 
>  On Fri, Apr 4, 2014 at 9:24 AM, Joan Touzet wrote:
> > Hi everyone,
> >
> > Time to summarize the results. You can view the results at
> >
> > https://docs.google.com/forms/d/1b7KcQGgNbSCZVRwLjrUl5Z6C2TBx8X1btlU5fwrNHpg/viewanalytics
> >   
> >
> > but I've included them in this email for ease of review.
> >
> > I'm going to break this up into sections and make some PROPOSALs. I'd
> > like to get general consensus on this vs. a "lazy" approach. I don't
> > see this as something where need a unanimous vote but I'd like to get us
> > all agree on something we can live with.
> >
> > As for getting this into the code base - let's not endanger the big
> > merges, but once we have finished them, we should move to these
> > standards piecemeal as we rework each file, as Noah and Jan suggest,
> > unless someone wants to do the busy work and re-indent everything.
> > Hopefully, even with the wait for the merges, this means the standard
> > can be "live" before the end of 2014 ;)
> >
> > I don't cover all topics in here - please feel free to follow the post's
> > format and add additional proposals in follow-ups.
> >
> > Finally, if I say something you disagree with or if I have 
> > misinterpreted
> > your response, speak up - it was not intentional!
> >
> > -Joan
> >
> > -
> >
> > TERMINOLOGY USED:
> > * "X space indent" means X spaces from the LEFT MARGIN.
> > It is the ABSOLUTE number of columns of whitespace on a line.
> >
> > * "Y space standard" means indentations should be multiples
> > of Y spaces.
> >
> > * "Z level indent" means Z*Y=X absolute spaces for the indent.
> > For a 4-space standard, a 2 level indent would mean an 8 space
> > indent.
> >
> > 

Re: [ANNOUNCE] Ben Bastian elected as CouchDB committer

[Dave Cottlehuber]

> Hey ho Ben - cool to have you on board - let's rock :)
>  
> On 10 October 2014 23:36, Benjamin Bastian wrote:
>  
> > Thanks all! I'm glad to officially be onboard.
> >
> > Ben


Sweet - welcome Ben :-))

A+, Dave

— sent from my Couch

[jira] [Commented] (COUCHDB-1863) Documentation link should be on top links of front page

[Dave Cottlehuber (JIRA)]

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

Dave Cottlehuber commented on COUCHDB-1863:
---

+1 for a link in nav bar that takes you direct to current release of rtd, e.g. 
http://docs.couchdb.org/en/1.6.1/contents.html BTW I have no idea why it thinks 
it 1.7.0; "Apache CouchDB™ 1.7.0-git Documentation". Sorry.

The Learn/Discuss section sounds good, but I think we are bikeshedding here. 
Let's fix the link, and then move on with the rest.

> Documentation link should be on top links of front page
> ---
>
> Key: COUCHDB-1863
> URL: https://issues.apache.org/jira/browse/COUCHDB-1863
> Project: CouchDB
>  Issue Type: Bug
>  Components: Website
>Reporter: Dale Harvey
>Assignee: Noah Slater
>
> Its about the most important link there and nobody (including me) can find it.
> Can send in a patch



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[TEST] Re: 1.6.1-rc4 binaries

[Dave Cottlehuber]

Hey folks,

I’ve transferred the mac snapshot I made into our official staging area, 
if you can confirm esp the .asc / .md5 / .sha match and confirm that 
`validate your install` works, that would be just peachy.

I expect to push these into the main (public) repo late Monday UTC.

https://dist.apache.org/repos/dist/dev/couchdb/binary/mac/1.6.1/rc.4/

Thanks!

—
Dave Cottlehuber
d...@jsonified.com
Sent from my Couch

Re: 1.6.1 OS X binaries missing!

[Dave Cottlehuber]

-Original Message-
From: Noah Slater 
Reply: dev@couchdb.apache.org >
Date: 10. September 2014 at 17:26:39
To: dev@couchdb.apache.org >
Subject:  1.6.1 OS X binaries missing!

> Hello folks,
>  
> I saw this today:
>  
> https://twitter.com/wjhuie/status/508636819760906241
>  
> I see from the ML archives that Jan prepared the OS X binaries, but
> there was an issue flagged with them.
>  
> Why did we proceed with the public release before this was fixed?
>  
> For clarification, I am not criticising Jan here, who is busy with JS
> Conf. I think we should have had a conversation about halting the
> release.

Hey Noah,

Thanks for raising this, it’s slipped between things.

There was a brief discussion between myself & Jan on IRC, and I didn’t
want to delay a significant patch release. My recollection is that we
don’t let source releases get dragged back unduly because of binaries.

The release announcement[0] does state that OSX is on the way, but there
is no specific info on the website about that.

While Jan’s done a huge pile of work in making the next OSX release
automated[1], I’m not sure whether this must run on Lion (which IIRC is
what the older build steps did) so we are waiting for some more of his
time to document / advise further. I don’t have a clean enough environment
to get this to work reliably enough for a release, will see tomorrow
if I can get a lion vm and try this out, it doesn’t work on either of my
macs here.

A+
Dave

[0]: http://blog.couchdb.org/2014/09/03/apache-couchdb-1-6-1-released/
[1]: https://github.com/janl/build-couchdb-mac/

Re: [ANNOUNCE] Jenn Schiffer elected as CouchDB committer

[Dave Cottlehuber]

-Original Message-
From: Noah Slater 
Reply: dev@couchdb.apache.org >
Date: 09. September 2014 at 16:06:51
To: dev@couchdb.apache.org >
Cc: j...@apache.org >
Subject:  [ANNOUNCE] Jenn Schiffer elected as CouchDB committer

> Dear community,
>  
> I am pleased to announce that the CouchDB Project Management Committee
> has elected Jenn Schiffer as a CouchDB committer.
>  
> Apache ID: jenn
>  
> IRC nick: jennmoneydollars
>  
> Twitter: jennschiffer
>  
> Committers are given a binding vote in certain project decsions, as
> well as write access to public project infrastructure.
>  
> This election was made in recognition of Jenn's commitment to the
> project. We mean this in the sense of being loyal to the project and
> its interests.
>  
> Please join me in extending a warm welcome to Jenn!
>  
> On behalf of the CouchDB PMC,

\o/ welcome on board Jenn! 

—
Dave Cottlehuber
d...@jsonified.com
Sent from my Couch

Re: automatic couchdb master builds

[Dave Cottlehuber]

Jan - sweet, I was assuming I could pick that up.

-Original Message-
From: Jan Lehnardt 
Reply: dev@couchdb.apache.org >
Date: 07. September 2014 at 18:55:16
To: dev@couchdb.apache.org >
Subject:  Re: automatic couchdb master builds

> ci.couchdb.org: does this already, it just hasn’t been updated to the new 
> build  
> steps in master, should be an easy fix though, if anyone wants to give it a 
> go.
>  
> Best
> Jan
> --
>  
> On 06 Sep 2014, at 22:11 , Dave Cottlehuber wrote:
>  
> > hey folks,
> >
> > Is it worthwhile me setting up ci & automatic builds now for master?
> >
> > I’d kept putting it off “because merge” but now seems like a good time to 
> > get this underway  
> again.
> >
> > —
> > Dave Cottlehuber
> > d...@jsonified.com
> > Sent from my Couch
> >
> >
>  
>  

—
Dave Cottlehuber
d...@jsonified.com
Sent from my Couch

automatic couchdb master builds

[Dave Cottlehuber]

hey folks,

Is it worthwhile me setting up ci & automatic builds now for master?

I’d kept putting it off “because merge” but now seems like a good time to get 
this underway again.

—
Dave Cottlehuber
d...@jsonified.com
Sent from my Couch

Re: [ANNOUNCE] Sebastian Rothbucher elected as CouchDB committer

[Dave Cottlehuber]

From: Noah Slater 
Reply: dev@couchdb.apache.org >
Date: 04. September 2014 at 16:49:40
To: dev@couchdb.apache.org >
Subject:  [ANNOUNCE] Sebastian Rothbucher elected as CouchDB committer

> > almosthenryford

Welcome Sebastian & congratulations!

—
Dave Cottlehuber
d...@jsonified.com
Sent from my Couch

[ANNOUNCE] Apache CouchDB 1.6.1 released

[Dave Cottlehuber]

Dear Community, 

Apache CouchDB 1.6.1 has been released and is available for download. 

CouchDB is a database that completely embraces the web. Store your data with
JSON documents. Access your documents with your web browser, via HTTP.
Query, combine, and transform your documents with JavaScript. CouchDB works
well with modern web and mobile apps. You can even serve web apps directly
out of CouchDB. And you can distribute your data, or your apps, efficiently
using CouchDB’s incremental replication. CouchDB supports master-master
setups with automatic conflict detection

Grab your copy here: 

http://couchdb.apache.org/ 

Pre-built packages for Windows are available, with OS X and Ubuntu packages
coming soon. The blog post will be updated when these are available.

CouchDB 1.6.1 is a patch release, and was originally published on 2014-09-03.

Further details at http://docs.couchdb.org/en/latest/whatsnew/1.6.html or
http://blog.couchdb.org/2014/09/03/apache-couchdb-1-6-1-released/

On behalf of the Apache CouchDB PMC, 

Dave Cottlehuber

Re: 1.6.1-rc4 binaries

[Dave Cottlehuber]

 
> Windows binaries are up for test at  
> https://dist.apache.org/repos/dist/dev/couchdb/binary/win/1.6.1/rc.4 (I  





perfect, tyvm.

>  
> hope it wasn't premature to put them there). There are files for R14B04 and  
> R16B02. Usual drill:  
>  
> 1. Download the files for your preferred version.  
> 2. Test signatures.  
> 3. Double-click the exe to install.  
> 4. Run couchdb.bat or start the service.  
> 5. Start Futon and verify the installation.  
> 6. Report your experience.  
>  
> Thank you,  
>  
> Nick  
>  

LGTM thanks Nick!

futon verify OK
sigs, sha, md5 OK

Do you want to `svn copy` these into 
https://dist.apache.org/repos/dist/release/couchdb/binary/win/ ?

—  
Dave Cottlehuber
d...@jsonified.com
Sent from my Couch

Subject: [RESULT] (Was: [VOTE] Release Apache CouchDB 1.6.1-rc.4)

[Dave Cottlehuber]

Dear community,

The vote has now closed, thank you to everyone who participated!

The results are:

-1:   0 votes
 0:   0 votes
+1:   5 votes

The vote has passed, with 5 votes.

http://mail-archives.apache.org/mod_mbox/couchdb-dev/201408.mbox/%3cetpan.53f68bd3.6b8b4567.f...@akai.skunkwerks.at%3E

—
Dave Cottlehuber
d...@jsonified.com
Sent from my Couch

Re: 1.6.1-rc4 binaries

[Dave Cottlehuber]

 


From: Jan Lehnardt (mailto:j...@apache.org)
Reply: dev@couchdb.apache.org >(mailto:dev@couchdb.apache.org)
Date: 31. August 2014 at 21:43:50
To: dev@couchdb.apache.org Developers >(mailto:dev@couchdb.apache.org)
Subject: 1.6.1-rc4 binaries

> Heya,
>  
> I’ve made Mac binaries for the ongoing 1.6.1 vote:
>  
> http://people.apache.org/~jan/dist/packages/mac/1.6.1/
>  
> Testing as usual:
>  
> - Download
> - Test signatures
> - Double click to unzip
> - Double click to start (make sure no other couch is running on port 5984)
> - Futon should open up in your browser. Navigate to “Verify Installation”, 
> and then verify your installation.
>  
> Do report the results :)
>  
> Note: This is baed on a completely new build process that is dependent on 
> Homebrew. This will make it possible for anyone to make binaries, and we will 
> even be able to make binaries as part of the CI setup, so we can get test 
> binaries for every commit. This should get users testing bugfixes early on! :)
>  
> I’ll write it all up and link it when I’ve got it all together.

+1 sig, sha, md5, verify relaxation.  

LGTM Jan, thanks.  

wrt to build process, there are some thing we could prune out, like libtool, 
aclocal & friends in ./Contents/Resources/couchdbx-core/share/ looking

I also tested homebrew before leaving, I’ll send a PR through for that when the 
release is announced.

—  
Dave Cottlehuber
d...@jsonified.com
Sent from my Couch

[jira] [Resolved] (COUCHDB-2299) admin users are unable to login after upgrading to 1.6.0 when older password hashes are used

[Dave Cottlehuber (JIRA)]

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

Dave Cottlehuber resolved COUCHDB-2299.
---

Resolution: Fixed

OK for me, thanks Bob.

> admin users are unable to login after upgrading to 1.6.0 when older password 
> hashes are used
> 
>
> Key: COUCHDB-2299
> URL: https://issues.apache.org/jira/browse/COUCHDB-2299
> Project: CouchDB
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Database Core
>Affects Versions: 1.6.0
>    Reporter: Dave Cottlehuber
>Assignee: Dave Cottlehuber
>Priority: Blocker
> Fix For: 1.6.1
>
>
> # issue
> When a couch is upgraded to 1.6.0, and the config files contain an [admins] 
> section with non-PBKDF2 hashed passwords (old-style < 1.3.1) then couchdb 
> will not let those admin users login.
> # reproduce
> - install 1.2.1 through 1.5.1 (tested those + 1.3.1 + 1.6.1-rc.3)
> - create a new admin user via futon
> - remove old binaries etc `rm -rf bin share lib` 
> - only dbs and .ini files remain (apart from log uri etc) 
> - install 1.6.0 (or 1-rc.3 with the fix for the raw/unhashed password fix) 
> - try to log in using admin via futon
> {code}
> 2> [debug] [<0.146.0>] 'POST' /_session {1,1} from "94.136.7.161"
> Headers: [{'Accept',"application/json"},
>   {'Accept-Encoding',"gzip,deflate"},
>   {'Accept-Language',"en-US,en;q=0.8,de;q=0.6"},
>   {'Connection',"keep-alive"},
>   {'Content-Length',"25"},
>   {'Content-Type',"application/x-www-form-urlencoded; charset=UTF-8"},
>   {'Cookie',"AuthSession="},
>   {"Dnt","1"},
>   {'Host',"130.211.98.121:5984"},
>   {"Origin","http://130.211.98.121:5984"},
>   {'Referer',"http://130.211.98.121:5984/_utils/"},
>   {'User-Agent',"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) 
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2129.0 Safari/537.36"},
>   {"X-Requested-With","XMLHttpRequest"}]
> [debug] [<0.146.0>] OAuth Params: []
> [debug] [<0.146.0>] Attempt Login: admin
> [debug] [<0.117.0>] DDocProc found for DDocKey: {<<"_design/_auth">>,
>  
> <<"2-7837bd4a550c1a65ac96c258e83d8b8c">>}
> [debug] [<0.171.0>] OS Process #Port<0.3041> Input  :: 
> ["reset",{"reduce_limit":true,"timeout":5000}]
> [debug] [<0.171.0>] OS Process #Port<0.3041> Output :: true
> [debug] [<0.171.0>] OS Process #Port<0.3041> Input  :: 
> ["ddoc","_design/_auth",
> ["validate_doc_update"],
> [{"_id":"",
> "password_scheme":"pbkdf2",
> "iterations":10,"roles":["_admin"],
> "salt":"a755d787383cdc147808a3ce2326479e",
> "password_scheme":"simple",
> "derived_key":"77bc076166db06fd940540ea7dc9d181e7e44741",
> "_revisions":{"start":0,"ids":[]}},
> null,
> {"db":"_users","name":null,"roles":["_admin"]},{}]]
> [debug] [<0.171.0>] OS Process #Port<0.3041> Output :: {"forbidden":"doc.type 
> must be user"}
> [debug] [<0.146.0>] Minor error in HTTP request: {forbidden,
>   <<"doc.type must be user">>}
> [debug] [<0.146.0>] Stacktrace: [{couch_db,update_doc,4,
>  [{file,"couch_db.erl"},{line,432}]},
>  {couch_httpd_auth,
>  '-maybe_upgrade_password_hash/3-fun-0-',
>  4,
>  [{file,"couch_httpd_auth.erl"},
>   {line,355}]},
>  {couch_util,with_db,2,
>  [{file,"couch_util.erl"},{line,443}]},
>  {couch_httpd_auth,handle_session_req,1,
>  [{file,"couch_httpd_auth.erl"},
>   {line,275}]},
>  {couch_httpd,handle_request_int,5,
>  [{file,"couch_httpd.erl"},{line,318}]},
>  {mochiweb_http,headers,5,
>  [{file,"mochiweb_http.erl"},{line,94}]},
>  {proc_lib,init_p_do_apply,3,
>  [{file,"proc_lib.erl"},{line,227}]}]
> [info] [<0.146.0>] 94.136.7.161 - - POST /_session 403
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [VOTE] Release Apache CouchDB 1.6.1-rc.4

[Dave Cottlehuber]

> Dear community,
>
> I would like to release Apache CouchDB 1.6.1-rc.4.
>
> Changes since last round:
>
> * include fix for COUCHDB-2299 (thanks Alexey Elfman for reporting this)
> * add a JIRA and docs for COUCHDB-2298 which was fixed in the last rc.3 
> already
> * 
> https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=shortlog;h=refs/heads/1.6.x
>
> We encourage the whole community to download and test these release artefacts 
> 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!
>
> The release artefacts we are voting on are available here:
>
> wget 
> https://dist.apache.org/repos/dist/dev/couchdb/source/1.6.1/rc.4/apache-couchdb-1.6.1.tar.gz
> wget 
> https://dist.apache.org/repos/dist/dev/couchdb/source/1.6.1/rc.4/apache-couchdb-1.6.1.tar.gz.asc
> wget 
> https://dist.apache.org/repos/dist/dev/couchdb/source/1.6.1/rc.4/apache-couchdb-1.6.1.tar.gz.ish
> wget 
> https://dist.apache.org/repos/dist/dev/couchdb/source/1.6.1/rc.4/apache-couchdb-1.6.1.tar.gz.md5
> wget 
> https://dist.apache.org/repos/dist/dev/couchdb/source/1.6.1/rc.4/apache-couchdb-1.6.1.tar.gz.sha
>
> Please follow the test procedure here:
>
> http://wiki.apache.org/couchdb/Test_procedure
>
> Please remember that "rc.4" is an annotation. If the vote passes, these 
> artefacts will be released as Apache CouchDB 1.6.1.
>
> Please cast your votes now.
>
> As I’ll be away from keyboards until 30th August, I’ll either pick this up 
> belatedly on my return or hope that a Nice Person picks it up in my absence.
>
> Thanks,
> Dave
>
> —
> Dave Cottlehuber
> d...@jsonified.com
> Sent from my Couch

+1  

sig, sha, md5, distcheck, verify install, upgrading OK  

Debian Wheezy 7.6 amd64 backports  
- OTP R15B01  
- Spidermonkey 1.8.5  

FreeBSD 10.0-STABLE amd64  
- OTP 17.1  
- Spidermonkey 1.8.5  

A+  
Dave

[VOTE] Release Apache CouchDB 1.6.1-rc.4

[Dave Cottlehuber]

Dear community,

I would like to release Apache CouchDB 1.6.1-rc.4.

Changes since last round:

 * include fix for COUCHDB-2299 (thanks Alexey Elfman for reporting this)
 * add a JIRA and docs for COUCHDB-2298 which was fixed in the last rc.3 already
 * 
https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=shortlog;h=refs/heads/1.6.x

We encourage the whole community to download and test these release artefacts 
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!

The release artefacts we are voting on are available here:

    wget 
https://dist.apache.org/repos/dist/dev/couchdb/source/1.6.1/rc.4/apache-couchdb-1.6.1.tar.gz
    wget 
https://dist.apache.org/repos/dist/dev/couchdb/source/1.6.1/rc.4/apache-couchdb-1.6.1.tar.gz.asc
    wget 
https://dist.apache.org/repos/dist/dev/couchdb/source/1.6.1/rc.4/apache-couchdb-1.6.1.tar.gz.ish
    wget 
https://dist.apache.org/repos/dist/dev/couchdb/source/1.6.1/rc.4/apache-couchdb-1.6.1.tar.gz.md5
    wget 
https://dist.apache.org/repos/dist/dev/couchdb/source/1.6.1/rc.4/apache-couchdb-1.6.1.tar.gz.sha

Please follow the test procedure here:

    http://wiki.apache.org/couchdb/Test_procedure

Please remember that "rc.4" is an annotation. If the vote passes, these 
artefacts will be released as Apache CouchDB 1.6.1.

Please cast your votes now.

As I’ll be away from keyboards until 30th August, I’ll either pick this up 
belatedly on my return or hope that a Nice Person picks it up in my absence.

Thanks,
Dave

— 
Dave Cottlehuber
d...@jsonified.com
Sent from my Couch

[jira] [Assigned] (COUCHDB-2299) admin users are unable to login after upgrading to 1.6.0 when older password hashes are used

[Dave Cottlehuber (JIRA)]

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

Dave Cottlehuber reassigned COUCHDB-2299:
-

Assignee: Dave Cottlehuber

> admin users are unable to login after upgrading to 1.6.0 when older password 
> hashes are used
> 
>
> Key: COUCHDB-2299
> URL: https://issues.apache.org/jira/browse/COUCHDB-2299
> Project: CouchDB
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Database Core
>Affects Versions: 1.6.0
>    Reporter: Dave Cottlehuber
>Assignee: Dave Cottlehuber
>Priority: Blocker
> Fix For: 1.6.1
>
>
> # issue
> When a couch is upgraded to 1.6.0, and the config files contain an [admins] 
> section with non-PBKDF2 hashed passwords (old-style < 1.3.1) then couchdb 
> will not let those admin users login.
> # reproduce
> - install 1.2.1 through 1.5.1 (tested those + 1.3.1 + 1.6.1-rc.3)
> - create a new admin user via futon
> - remove old binaries etc `rm -rf bin share lib` 
> - only dbs and .ini files remain (apart from log uri etc) 
> - install 1.6.0 (or 1-rc.3 with the fix for the raw/unhashed password fix) 
> - try to log in using admin via futon
> {code}
> 2> [debug] [<0.146.0>] 'POST' /_session {1,1} from "94.136.7.161"
> Headers: [{'Accept',"application/json"},
>   {'Accept-Encoding',"gzip,deflate"},
>   {'Accept-Language',"en-US,en;q=0.8,de;q=0.6"},
>   {'Connection',"keep-alive"},
>   {'Content-Length',"25"},
>   {'Content-Type',"application/x-www-form-urlencoded; charset=UTF-8"},
>   {'Cookie',"AuthSession="},
>   {"Dnt","1"},
>   {'Host',"130.211.98.121:5984"},
>   {"Origin","http://130.211.98.121:5984"},
>   {'Referer',"http://130.211.98.121:5984/_utils/"},
>   {'User-Agent',"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) 
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2129.0 Safari/537.36"},
>   {"X-Requested-With","XMLHttpRequest"}]
> [debug] [<0.146.0>] OAuth Params: []
> [debug] [<0.146.0>] Attempt Login: admin
> [debug] [<0.117.0>] DDocProc found for DDocKey: {<<"_design/_auth">>,
>  
> <<"2-7837bd4a550c1a65ac96c258e83d8b8c">>}
> [debug] [<0.171.0>] OS Process #Port<0.3041> Input  :: 
> ["reset",{"reduce_limit":true,"timeout":5000}]
> [debug] [<0.171.0>] OS Process #Port<0.3041> Output :: true
> [debug] [<0.171.0>] OS Process #Port<0.3041> Input  :: 
> ["ddoc","_design/_auth",
> ["validate_doc_update"],
> [{"_id":"",
> "password_scheme":"pbkdf2",
> "iterations":10,"roles":["_admin"],
> "salt":"a755d787383cdc147808a3ce2326479e",
> "password_scheme":"simple",
> "derived_key":"77bc076166db06fd940540ea7dc9d181e7e44741",
> "_revisions":{"start":0,"ids":[]}},
> null,
> {"db":"_users","name":null,"roles":["_admin"]},{}]]
> [debug] [<0.171.0>] OS Process #Port<0.3041> Output :: {"forbidden":"doc.type 
> must be user"}
> [debug] [<0.146.0>] Minor error in HTTP request: {forbidden,
>   <<"doc.type must be user">>}
> [debug] [<0.146.0>] Stacktrace: [{couch_db,update_doc,4,
>  [{file,"couch_db.erl"},{line,432}]},
>  {couch_httpd_auth,
>  '-maybe_upgrade_password_hash/3-fun-0-',
>  4,
>  [{file,"couch_httpd_auth.erl"},
>   {line,355}]},
>  {couch_util,with_db,2,
>  [{file,"couch_util.erl"},{line,443}]},
>  {couch_httpd_auth,handle_session_req,1,
>  [{file,"couch_httpd_auth.erl"},
>   {line,275}]},
>  {couch_httpd,handle_request_int,5,
>  [{file,"couch_httpd.erl"},{line,318}]},
>  {mochiweb_http,headers,5,
>  [{file,"mochiweb_http.erl"},{line,94}]},
>  {proc_lib,init_p_do_apply,3,
>  [{file,"proc_lib.erl"},{line,227}]}]
> [info] [<0.146.0>] 94.136.7.161 - - POST /_session 403
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (COUCHDB-2299) admin users are unable to login after upgrading to 1.6.0 when older password hashes are used

[Dave Cottlehuber (JIRA)]

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

Dave Cottlehuber commented on COUCHDB-2299:
---

work-around for those who have already installed is either to:

a. roll back to 1.5.1
b. wait for an official fix or (sotto voce if you can't roll back and can't 
wait)
c. install 1.6.1-rc.3 candidate and add a plain-text admin to your local.ini:

[admins]
workaround = passwd

then log in using workaround. You can manually update/fix other admin passwords 
from there.


> admin users are unable to login after upgrading to 1.6.0 when older password 
> hashes are used
> 
>
> Key: COUCHDB-2299
> URL: https://issues.apache.org/jira/browse/COUCHDB-2299
> Project: CouchDB
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Database Core
>Affects Versions: 1.6.0
>Reporter: Dave Cottlehuber
>Priority: Blocker
> Fix For: 1.6.1
>
>
> # issue
> When a couch is upgraded to 1.6.0, and the config files contain an [admins] 
> section with non-PBKDF2 hashed passwords (old-style < 1.3.1) then couchdb 
> will not let those admin users login.
> # reproduce
> - install 1.2.1 through 1.5.1 (tested those + 1.3.1 + 1.6.1-rc.3)
> - create a new admin user via futon
> - remove old binaries etc `rm -rf bin share lib` 
> - only dbs and .ini files remain (apart from log uri etc) 
> - install 1.6.0 (or 1-rc.3 with the fix for the raw/unhashed password fix) 
> - try to log in using admin via futon
> {code}
> 2> [debug] [<0.146.0>] 'POST' /_session {1,1} from "94.136.7.161"
> Headers: [{'Accept',"application/json"},
>   {'Accept-Encoding',"gzip,deflate"},
>   {'Accept-Language',"en-US,en;q=0.8,de;q=0.6"},
>   {'Connection',"keep-alive"},
>   {'Content-Length',"25"},
>   {'Content-Type',"application/x-www-form-urlencoded; charset=UTF-8"},
>   {'Cookie',"AuthSession="},
>   {"Dnt","1"},
>   {'Host',"130.211.98.121:5984"},
>   {"Origin","http://130.211.98.121:5984"},
>   {'Referer',"http://130.211.98.121:5984/_utils/"},
>   {'User-Agent',"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) 
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2129.0 Safari/537.36"},
>   {"X-Requested-With","XMLHttpRequest"}]
> [debug] [<0.146.0>] OAuth Params: []
> [debug] [<0.146.0>] Attempt Login: admin
> [debug] [<0.117.0>] DDocProc found for DDocKey: {<<"_design/_auth">>,
>  
> <<"2-7837bd4a550c1a65ac96c258e83d8b8c">>}
> [debug] [<0.171.0>] OS Process #Port<0.3041> Input  :: 
> ["reset",{"reduce_limit":true,"timeout":5000}]
> [debug] [<0.171.0>] OS Process #Port<0.3041> Output :: true
> [debug] [<0.171.0>] OS Process #Port<0.3041> Input  :: 
> ["ddoc","_design/_auth",
> ["validate_doc_update"],
> [{"_id":"",
> "password_scheme":"pbkdf2",
> "iterations":10,"roles":["_admin"],
> "salt":"a755d787383cdc147808a3ce2326479e",
> "password_scheme":"simple",
> "derived_key":"77bc076166db06fd940540ea7dc9d181e7e44741",
> "_revisions":{"start":0,"ids":[]}},
> null,
> {"db":"_users","name":null,"roles":["_admin"]},{}]]
> [debug] [<0.171.0>] OS Process #Port<0.3041> Output :: {"forbidden":"doc.type 
> must be user"}
> [debug] [<0.146.0>] Minor error in HTTP request: {forbidden,
>   <<"doc.type must be user">>}
> [debug] [<0.146.0>] Stacktrace: [{couch_db,update_doc,4,
>  [{file,"couch_db.erl"},{line,432}]},
>  {couch_httpd_auth,
>  '-maybe_upgrade_password_hash/3-fun-0-',
>

Re: [VOTE] Release Apache CouchDB 1.6.1-rc.3

[Dave Cottlehuber]

> +1 Gentoo / Erlang 17.1 / SpiderMonkey 1.8.5
>  
> sig, sha, distcheck are ok, password issue is fixed.
>  
> --
> ,,,^..^,,,

Sadly we’ll need to abort this one too. See 
https://issues.apache.org/jira/browse/COUCHDB-2299 for why.

Also, I’ll be on vacation til 31st August from tomorrow morning onwards so I 
can’t progress this further.

If anybody else wants to pick up the RM hat for this one please do.

We should also send some notification out about this issue, and an appropriate 
work-around if the release is going to be delayed. I’ll check in this evening.

A+
Dave

[jira] [Commented] (COUCHDB-2299) admin users are unable to login after upgrading to 1.6.0 when older password hashes are used

[Dave Cottlehuber (JIRA)]

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

Dave Cottlehuber commented on COUCHDB-2299:
---

Note that 1.4+ obviously won't have the actual issue, because they will create 
PKBDF2-style hashes, but if the [admins] section hasn't changed from a previous 
install, it will still fail. 1.6.0 is where we broke this.

> admin users are unable to login after upgrading to 1.6.0 when older password 
> hashes are used
> 
>
> Key: COUCHDB-2299
> URL: https://issues.apache.org/jira/browse/COUCHDB-2299
> Project: CouchDB
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Database Core
>Affects Versions: 1.6.0
>Reporter: Dave Cottlehuber
>Priority: Blocker
> Fix For: 1.6.1
>
>
> # issue
> When a couch is upgraded to 1.6.0, and the config files contain an [admins] 
> section with non-PBKDF2 hashed passwords (old-style < 1.3.1) then couchdb 
> will not let those admin users login.
> # reproduce
> - install 1.2.1 through 1.5.1 (tested those + 1.3.1 + 1.6.1-rc.3)
> - create a new admin user via futon
> - remove old binaries etc `rm -rf bin share lib` 
> - only dbs and .ini files remain (apart from log uri etc) 
> - install 1.6.0 (or 1-rc.3 with the fix for the raw/unhashed password fix) 
> - try to log in using admin via futon
> {code}
> 2> [debug] [<0.146.0>] 'POST' /_session {1,1} from "94.136.7.161"
> Headers: [{'Accept',"application/json"},
>   {'Accept-Encoding',"gzip,deflate"},
>   {'Accept-Language',"en-US,en;q=0.8,de;q=0.6"},
>   {'Connection',"keep-alive"},
>   {'Content-Length',"25"},
>   {'Content-Type',"application/x-www-form-urlencoded; charset=UTF-8"},
>   {'Cookie',"AuthSession="},
>   {"Dnt","1"},
>   {'Host',"130.211.98.121:5984"},
>   {"Origin","http://130.211.98.121:5984"},
>   {'Referer',"http://130.211.98.121:5984/_utils/"},
>   {'User-Agent',"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) 
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2129.0 Safari/537.36"},
>   {"X-Requested-With","XMLHttpRequest"}]
> [debug] [<0.146.0>] OAuth Params: []
> [debug] [<0.146.0>] Attempt Login: admin
> [debug] [<0.117.0>] DDocProc found for DDocKey: {<<"_design/_auth">>,
>  
> <<"2-7837bd4a550c1a65ac96c258e83d8b8c">>}
> [debug] [<0.171.0>] OS Process #Port<0.3041> Input  :: 
> ["reset",{"reduce_limit":true,"timeout":5000}]
> [debug] [<0.171.0>] OS Process #Port<0.3041> Output :: true
> [debug] [<0.171.0>] OS Process #Port<0.3041> Input  :: 
> ["ddoc","_design/_auth",
> ["validate_doc_update"],
> [{"_id":"",
> "password_scheme":"pbkdf2",
> "iterations":10,"roles":["_admin"],
> "salt":"a755d787383cdc147808a3ce2326479e",
> "password_scheme":"simple",
> "derived_key":"77bc076166db06fd940540ea7dc9d181e7e44741",
> "_revisions":{"start":0,"ids":[]}},
> null,
> {"db":"_users","name":null,"roles":["_admin"]},{}]]
> [debug] [<0.171.0>] OS Process #Port<0.3041> Output :: {"forbidden":"doc.type 
> must be user"}
> [debug] [<0.146.0>] Minor error in HTTP request: {forbidden,
>   <<"doc.type must be user">>}
> [debug] [<0.146.0>] Stacktrace: [{couch_db,update_doc,4,
>  [{file,"couch_db.erl"},{line,432}]},
>  {couch_httpd_auth,
>  '-maybe_upgrade_password_hash/3-fun-0-',
>  4,
>  [{file,"couch_httpd_auth.erl"},
>   {line,355}]},
>  {couch_util,with_db,2,
>  [{file,"couch_util.erl"},{line,443}]},
>  {couch_httpd_auth,handle_session_req,1,
>  [{file,"couch_httpd_auth.erl"},
>   {line,275}]},
>  {couch_httpd,handle_request_int,5,
>  [{file,"couch_httpd.erl"},{line,318}]},
>  {mochiweb_http,headers,5,
>  [{file,"mochiweb_http.erl"},{line,94}]},
>  {proc_lib,init_p_do_apply,3,
>  [{file,"proc_lib.erl"},{line,227}]}]
> [info] [<0.146.0>] 94.136.7.161 - - POST /_session 403
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (COUCHDB-2299) admin users are unable to login after upgrading to 1.6.0 when older password hashes are used

[Dave Cottlehuber (JIRA)]

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

Dave Cottlehuber updated COUCHDB-2299:
--

Fix Version/s: 1.6.1

> admin users are unable to login after upgrading to 1.6.0 when older password 
> hashes are used
> 
>
> Key: COUCHDB-2299
> URL: https://issues.apache.org/jira/browse/COUCHDB-2299
> Project: CouchDB
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Database Core
>Affects Versions: 1.6.0
>    Reporter: Dave Cottlehuber
>Priority: Blocker
> Fix For: 1.6.1
>
>
> # issue
> When a couch is upgraded to 1.6.0, and the config files contain an [admins] 
> section with non-PBKDF2 hashed passwords (old-style < 1.3.1) then couchdb 
> will not let those admin users login.
> # reproduce
> - install 1.2.1 through 1.5.1 (tested those + 1.3.1 + 1.6.1-rc.3)
> - create a new admin user via futon
> - remove old binaries etc `rm -rf bin share lib` 
> - only dbs and .ini files remain (apart from log uri etc) 
> - install 1.6.0 (or 1-rc.3 with the fix for the raw/unhashed password fix) 
> - try to log in using admin via futon
> {code}
> 2> [debug] [<0.146.0>] 'POST' /_session {1,1} from "94.136.7.161"
> Headers: [{'Accept',"application/json"},
>   {'Accept-Encoding',"gzip,deflate"},
>   {'Accept-Language',"en-US,en;q=0.8,de;q=0.6"},
>   {'Connection',"keep-alive"},
>   {'Content-Length',"25"},
>   {'Content-Type',"application/x-www-form-urlencoded; charset=UTF-8"},
>   {'Cookie',"AuthSession="},
>   {"Dnt","1"},
>   {'Host',"130.211.98.121:5984"},
>   {"Origin","http://130.211.98.121:5984"},
>   {'Referer',"http://130.211.98.121:5984/_utils/"},
>   {'User-Agent',"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) 
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2129.0 Safari/537.36"},
>   {"X-Requested-With","XMLHttpRequest"}]
> [debug] [<0.146.0>] OAuth Params: []
> [debug] [<0.146.0>] Attempt Login: admin
> [debug] [<0.117.0>] DDocProc found for DDocKey: {<<"_design/_auth">>,
>  
> <<"2-7837bd4a550c1a65ac96c258e83d8b8c">>}
> [debug] [<0.171.0>] OS Process #Port<0.3041> Input  :: 
> ["reset",{"reduce_limit":true,"timeout":5000}]
> [debug] [<0.171.0>] OS Process #Port<0.3041> Output :: true
> [debug] [<0.171.0>] OS Process #Port<0.3041> Input  :: 
> ["ddoc","_design/_auth",
> ["validate_doc_update"],
> [{"_id":"",
> "password_scheme":"pbkdf2",
> "iterations":10,"roles":["_admin"],
> "salt":"a755d787383cdc147808a3ce2326479e",
> "password_scheme":"simple",
> "derived_key":"77bc076166db06fd940540ea7dc9d181e7e44741",
> "_revisions":{"start":0,"ids":[]}},
> null,
> {"db":"_users","name":null,"roles":["_admin"]},{}]]
> [debug] [<0.171.0>] OS Process #Port<0.3041> Output :: {"forbidden":"doc.type 
> must be user"}
> [debug] [<0.146.0>] Minor error in HTTP request: {forbidden,
>   <<"doc.type must be user">>}
> [debug] [<0.146.0>] Stacktrace: [{couch_db,update_doc,4,
>  [{file,"couch_db.erl"},{line,432}]},
>  {couch_httpd_auth,
>  '-maybe_upgrade_password_hash/3-fun-0-',
>  4,
>  [{file,"couch_httpd_auth.erl"},
>   {line,355}]},
>  {couch_util,with_db,2,
>  [{file,"couch_util.erl"},{line,443}]},
>  {couch_httpd_auth,handle_session_req,1,
>  [{file,"couch_httpd_auth.erl"},
>   {line,275}]},
>  {couch_httpd,handle_request_int,5,
>  [{file,"couch_httpd.erl"},{line,318}]},
>  {mochiweb_http,headers,5,
>  [{file,"mochiweb_http.erl"},{line,94}]},
>  {proc_lib,init_p_do_apply,3,
>  [{file,"proc_lib.erl"},{line,227}]}]
> [info] [<0.146.0>] 94.136.7.161 - - POST /_session 403
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (COUCHDB-2299) admin users are unable to login after upgrading to 1.6.0 when older password hashes are used

[Dave Cottlehuber (JIRA)]

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

Dave Cottlehuber updated COUCHDB-2299:
--

Affects Version/s: 1.6.0

> admin users are unable to login after upgrading to 1.6.0 when older password 
> hashes are used
> 
>
> Key: COUCHDB-2299
> URL: https://issues.apache.org/jira/browse/COUCHDB-2299
> Project: CouchDB
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Database Core
>Affects Versions: 1.6.0
>    Reporter: Dave Cottlehuber
>Priority: Blocker
> Fix For: 1.6.1
>
>
> # issue
> When a couch is upgraded to 1.6.0, and the config files contain an [admins] 
> section with non-PBKDF2 hashed passwords (old-style < 1.3.1) then couchdb 
> will not let those admin users login.
> # reproduce
> - install 1.2.1 through 1.5.1 (tested those + 1.3.1 + 1.6.1-rc.3)
> - create a new admin user via futon
> - remove old binaries etc `rm -rf bin share lib` 
> - only dbs and .ini files remain (apart from log uri etc) 
> - install 1.6.0 (or 1-rc.3 with the fix for the raw/unhashed password fix) 
> - try to log in using admin via futon
> {code}
> 2> [debug] [<0.146.0>] 'POST' /_session {1,1} from "94.136.7.161"
> Headers: [{'Accept',"application/json"},
>   {'Accept-Encoding',"gzip,deflate"},
>   {'Accept-Language',"en-US,en;q=0.8,de;q=0.6"},
>   {'Connection',"keep-alive"},
>   {'Content-Length',"25"},
>   {'Content-Type',"application/x-www-form-urlencoded; charset=UTF-8"},
>   {'Cookie',"AuthSession="},
>   {"Dnt","1"},
>   {'Host',"130.211.98.121:5984"},
>   {"Origin","http://130.211.98.121:5984"},
>   {'Referer',"http://130.211.98.121:5984/_utils/"},
>   {'User-Agent',"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) 
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2129.0 Safari/537.36"},
>   {"X-Requested-With","XMLHttpRequest"}]
> [debug] [<0.146.0>] OAuth Params: []
> [debug] [<0.146.0>] Attempt Login: admin
> [debug] [<0.117.0>] DDocProc found for DDocKey: {<<"_design/_auth">>,
>  
> <<"2-7837bd4a550c1a65ac96c258e83d8b8c">>}
> [debug] [<0.171.0>] OS Process #Port<0.3041> Input  :: 
> ["reset",{"reduce_limit":true,"timeout":5000}]
> [debug] [<0.171.0>] OS Process #Port<0.3041> Output :: true
> [debug] [<0.171.0>] OS Process #Port<0.3041> Input  :: 
> ["ddoc","_design/_auth",
> ["validate_doc_update"],
> [{"_id":"",
> "password_scheme":"pbkdf2",
> "iterations":10,"roles":["_admin"],
> "salt":"a755d787383cdc147808a3ce2326479e",
> "password_scheme":"simple",
> "derived_key":"77bc076166db06fd940540ea7dc9d181e7e44741",
> "_revisions":{"start":0,"ids":[]}},
> null,
> {"db":"_users","name":null,"roles":["_admin"]},{}]]
> [debug] [<0.171.0>] OS Process #Port<0.3041> Output :: {"forbidden":"doc.type 
> must be user"}
> [debug] [<0.146.0>] Minor error in HTTP request: {forbidden,
>   <<"doc.type must be user">>}
> [debug] [<0.146.0>] Stacktrace: [{couch_db,update_doc,4,
>  [{file,"couch_db.erl"},{line,432}]},
>  {couch_httpd_auth,
>  '-maybe_upgrade_password_hash/3-fun-0-',
>  4,
>  [{file,"couch_httpd_auth.erl"},
>   {line,355}]},
>  {couch_util,with_db,2,
>  [{file,"couch_util.erl"},{line,443}]},
>  {couch_httpd_auth,handle_session_req,1,
>  [{file,"couch_httpd_auth.erl"},
>   {line,275}]},
>  {couch_httpd,handle_request_int,5,
>  [{file,"couch_httpd.erl"},{line,318}]},
>  {mochiweb_http,headers,5,
>  [{file,"mochiweb_http.erl"},{line,94}]},
>  {proc_lib,init_p_do_apply,3,
>  [{file,"proc_lib.erl"},{line,227}]}]
> [info] [<0.146.0>] 94.136.7.161 - - POST /_session 403
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (COUCHDB-2299) admin users are unable to login after upgrading to 1.6.0 when older password hashes are used

[Dave Cottlehuber (JIRA)]

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

Dave Cottlehuber updated COUCHDB-2299:
--

Priority: Blocker  (was: Major)

> admin users are unable to login after upgrading to 1.6.0 when older password 
> hashes are used
> 
>
> Key: COUCHDB-2299
> URL: https://issues.apache.org/jira/browse/COUCHDB-2299
> Project: CouchDB
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Database Core
>    Reporter: Dave Cottlehuber
>Priority: Blocker
>
> # issue
> When a couch is upgraded to 1.6.0, and the config files contain an [admins] 
> section with non-PBKDF2 hashed passwords (old-style < 1.3.1) then couchdb 
> will not let those admin users login.
> # reproduce
> - install 1.2.1 through 1.5.1 (tested those + 1.3.1 + 1.6.1-rc.3)
> - create a new admin user via futon
> - remove old binaries etc `rm -rf bin share lib` 
> - only dbs and .ini files remain (apart from log uri etc) 
> - install 1.6.0 (or 1-rc.3 with the fix for the raw/unhashed password fix) 
> - try to log in using admin via futon
> {code}
> 2> [debug] [<0.146.0>] 'POST' /_session {1,1} from "94.136.7.161"
> Headers: [{'Accept',"application/json"},
>   {'Accept-Encoding',"gzip,deflate"},
>   {'Accept-Language',"en-US,en;q=0.8,de;q=0.6"},
>   {'Connection',"keep-alive"},
>   {'Content-Length',"25"},
>   {'Content-Type',"application/x-www-form-urlencoded; charset=UTF-8"},
>   {'Cookie',"AuthSession="},
>   {"Dnt","1"},
>   {'Host',"130.211.98.121:5984"},
>   {"Origin","http://130.211.98.121:5984"},
>   {'Referer',"http://130.211.98.121:5984/_utils/"},
>   {'User-Agent',"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) 
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2129.0 Safari/537.36"},
>   {"X-Requested-With","XMLHttpRequest"}]
> [debug] [<0.146.0>] OAuth Params: []
> [debug] [<0.146.0>] Attempt Login: admin
> [debug] [<0.117.0>] DDocProc found for DDocKey: {<<"_design/_auth">>,
>  
> <<"2-7837bd4a550c1a65ac96c258e83d8b8c">>}
> [debug] [<0.171.0>] OS Process #Port<0.3041> Input  :: 
> ["reset",{"reduce_limit":true,"timeout":5000}]
> [debug] [<0.171.0>] OS Process #Port<0.3041> Output :: true
> [debug] [<0.171.0>] OS Process #Port<0.3041> Input  :: 
> ["ddoc","_design/_auth",
> ["validate_doc_update"],
> [{"_id":"",
> "password_scheme":"pbkdf2",
> "iterations":10,"roles":["_admin"],
> "salt":"a755d787383cdc147808a3ce2326479e",
> "password_scheme":"simple",
> "derived_key":"77bc076166db06fd940540ea7dc9d181e7e44741",
> "_revisions":{"start":0,"ids":[]}},
> null,
> {"db":"_users","name":null,"roles":["_admin"]},{}]]
> [debug] [<0.171.0>] OS Process #Port<0.3041> Output :: {"forbidden":"doc.type 
> must be user"}
> [debug] [<0.146.0>] Minor error in HTTP request: {forbidden,
>   <<"doc.type must be user">>}
> [debug] [<0.146.0>] Stacktrace: [{couch_db,update_doc,4,
>  [{file,"couch_db.erl"},{line,432}]},
>  {couch_httpd_auth,
>  '-maybe_upgrade_password_hash/3-fun-0-',
>  4,
>  [{file,"couch_httpd_auth.erl"},
>   {line,355}]},
>  {couch_util,with_db,2,
>  [{file,"couch_util.erl"},{line,443}]},
>  {couch_httpd_auth,handle_session_req,1,
>  [{file,"couch_httpd_auth.erl"},
>   {line,275}]},
>  {couch_httpd,handle_request_int,5,
>  [{file,"couch_httpd.erl"},{line,318}]},
>  {mochiweb_http,headers,5,
>  [{file,"mochiweb_http.erl"},{line,94}]},
>  {proc_lib,init_p_do_apply,3,
>  [{file,"proc_lib.erl"},{line,227}]}]
> [info] [<0.146.0>] 94.136.7.161 - - POST /_session 403
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (COUCHDB-2299) admin users are unable to login after upgrading to 1.6.0 when older password hashes are used

[Dave Cottlehuber (JIRA)]

Dave Cottlehuber created COUCHDB-2299:
-

 Summary: admin users are unable to login after upgrading to 1.6.0 
when older password hashes are used
 Key: COUCHDB-2299
 URL: https://issues.apache.org/jira/browse/COUCHDB-2299
 Project: CouchDB
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: Database Core
Reporter: Dave Cottlehuber


# issue

When a couch is upgraded to 1.6.0, and the config files contain an [admins] 
section with non-PBKDF2 hashed passwords (old-style < 1.3.1) then couchdb will 
not let those admin users login.

# reproduce

- install 1.2.1 through 1.5.1 (tested those + 1.3.1 + 1.6.1-rc.3)
- create a new admin user via futon
- remove old binaries etc `rm -rf bin share lib` 
- only dbs and .ini files remain (apart from log uri etc) 
- install 1.6.0 (or 1-rc.3 with the fix for the raw/unhashed password fix) 
- try to log in using admin via futon

{code}
2> [debug] [<0.146.0>] 'POST' /_session {1,1} from "94.136.7.161"
Headers: [{'Accept',"application/json"},
  {'Accept-Encoding',"gzip,deflate"},
  {'Accept-Language',"en-US,en;q=0.8,de;q=0.6"},
  {'Connection',"keep-alive"},
  {'Content-Length',"25"},
  {'Content-Type',"application/x-www-form-urlencoded; charset=UTF-8"},
  {'Cookie',"AuthSession="},
  {"Dnt","1"},
  {'Host',"130.211.98.121:5984"},
  {"Origin","http://130.211.98.121:5984"},
  {'Referer',"http://130.211.98.121:5984/_utils/"},
  {'User-Agent',"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2129.0 Safari/537.36"},
  {"X-Requested-With","XMLHttpRequest"}]
[debug] [<0.146.0>] OAuth Params: []
[debug] [<0.146.0>] Attempt Login: admin
[debug] [<0.117.0>] DDocProc found for DDocKey: {<<"_design/_auth">>,
 
<<"2-7837bd4a550c1a65ac96c258e83d8b8c">>}
[debug] [<0.171.0>] OS Process #Port<0.3041> Input  :: 
["reset",{"reduce_limit":true,"timeout":5000}]
[debug] [<0.171.0>] OS Process #Port<0.3041> Output :: true
[debug] [<0.171.0>] OS Process #Port<0.3041> Input  :: ["ddoc","_design/_auth",
["validate_doc_update"],
[{"_id":"",
"password_scheme":"pbkdf2",
"iterations":10,"roles":["_admin"],
"salt":"a755d787383cdc147808a3ce2326479e",
"password_scheme":"simple",
"derived_key":"77bc076166db06fd940540ea7dc9d181e7e44741",
"_revisions":{"start":0,"ids":[]}},
null,
{"db":"_users","name":null,"roles":["_admin"]},{}]]
[debug] [<0.171.0>] OS Process #Port<0.3041> Output :: {"forbidden":"doc.type 
must be user"}
[debug] [<0.146.0>] Minor error in HTTP request: {forbidden,
  <<"doc.type must be user">>}
[debug] [<0.146.0>] Stacktrace: [{couch_db,update_doc,4,
 [{file,"couch_db.erl"},{line,432}]},
 {couch_httpd_auth,
 '-maybe_upgrade_password_hash/3-fun-0-',
 4,
 [{file,"couch_httpd_auth.erl"},
  {line,355}]},
 {couch_util,with_db,2,
 [{file,"couch_util.erl"},{line,443}]},
 {couch_httpd_auth,handle_session_req,1,
 [{file,"couch_httpd_auth.erl"},
  {line,275}]},
 {couch_httpd,handle_request_int,5,
 [{file,"couch_httpd.erl"},{line,318}]},
 {mochiweb_http,headers,5,
 [{file,"mochiweb_http.erl"},{line,94}]},
 {proc_lib,init_p_do_apply,3,
 [{file,"proc_lib.erl"},{line,227}]}]
[info] [<0.146.0>] 94.136.7.161 - - POST /_session 403
{code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: old-style (hashed) passwords for admin are broken in 1.6.0?

[Dave Cottlehuber]

 
> On Thu, Aug 21, 2014 at 4:33 PM, James Dingwall  
> wrote:  
> > Alexey Elfman wrote:  
> >>  
> >> Hello.  
> >>  
> >> I've experiencing troubles after upgrade to 1.6.0.  
> >> After short investigation, I realized, that troubles are with admin users  
> >> with hashed password (not pbkdf) in locals.ini file.  
> >>  
> >> Users with hashed password experiencing 403 error accessing couchdb 1.6.0  
> >> (all previous versions work fine). Error text isn't helpfull:  
> >> "{"error":"forbidden","reason":"doc.type must be user"}"  
> >>  
> >> So, my recommendation is to reset password before upgrade (it will become  
> >> in pbkdf format).  
> >>  
> >> This trouble (breaking change?) was not covered in change log for 1.6.0,  
> >> so, may be, my message will be helpfull for somebody.  
> >>  
> > This was a bug in the 1.6.0 release. You can apply a patch to the source to 
> >  
> > solve the problem.  
> >  
> > Regards,  
> > James  


Thanks for reporting this Alexey, unless I’m missing something, this seems to 
be a
*different* problem, I’ve struck this too this morning.

Alexey - what version of CouchDB were you running prior?

repro:

- install 1.2.1
- create admin, bdmin users via futon
- remove old binaries etc `rm -rf bin share lib`
  only dbs and .ini files remain (apart from log uri etc)
- install 1.6.0 (or 1-rc.3 with the fix for the raw/unhashed password fix)
- try to log in using admin or bdmin via futon

See https://dpaste.de/XRfY for more details.

CC’ing dev.

—
Dave Cottlehuber
d...@jsonified.com
Sent from my Couch

[jira] [Closed] (COUCHDB-2298) 1.6.0 crashes on startup if plain (non-hashed) admins are present in .ini / config files

[Dave Cottlehuber (JIRA)]

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

Dave Cottlehuber closed COUCHDB-2298.
-


> 1.6.0 crashes on startup if plain (non-hashed) admins are present in .ini / 
> config files
> 
>
> Key: COUCHDB-2298
> URL: https://issues.apache.org/jira/browse/COUCHDB-2298
> Project: CouchDB
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Database Core
>    Reporter: Dave Cottlehuber
>    Assignee: Dave Cottlehuber
> Fix For: 1.6.1
>
>
> If a couchdb install is managed via e.g. chef or similar, and the admin 
> passwords are pushed as plaintext, couchdb will crash on startup.
> {code}
> 1> Apache CouchDB 1.6.0 (LogLevel=info) is starting.
> {"init terminating in do_boot",{{badmatch,{error,{bad_return, 
> {{couch_app,start,[normal,["/ramdisk/couch/etc/couchdb/default.ini","/ramdisk/couch/etc/couchdb/local.ini"]]},{'EXIT',{{badmatch,{error,shutdown}},[{couch_server_sup,start_server,1,[{file,"couch_server_sup.erl"},{line,98}]},{application_master,start_it_old,4,[{file,"application_master.erl"},{line,274}]}]}},[{couch,start,0,[{file,"couch.erl"},{line,18}]},{init,start_it,1,[]},{init,start_em,1,[]}]}}
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (COUCHDB-2298) 1.6.0 crashes on startup if plain (non-hashed) admins are present in .ini / config files

[Dave Cottlehuber (JIRA)]

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

Dave Cottlehuber resolved COUCHDB-2298.
---

Resolution: Fixed

fixed by [~rnewson] in [#d43f69d | 
https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commitdiff;h=d43f69d] 
on master, and in [#ed825d3 | 
https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commitdiff;h=ed825d3 ] 
in 1.6.x

> 1.6.0 crashes on startup if plain (non-hashed) admins are present in .ini / 
> config files
> 
>
> Key: COUCHDB-2298
> URL: https://issues.apache.org/jira/browse/COUCHDB-2298
> Project: CouchDB
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Database Core
>    Reporter: Dave Cottlehuber
>    Assignee: Dave Cottlehuber
> Fix For: 1.6.1
>
>
> If a couchdb install is managed via e.g. chef or similar, and the admin 
> passwords are pushed as plaintext, couchdb will crash on startup.
> {code}
> 1> Apache CouchDB 1.6.0 (LogLevel=info) is starting.
> {"init terminating in do_boot",{{badmatch,{error,{bad_return, 
> {{couch_app,start,[normal,["/ramdisk/couch/etc/couchdb/default.ini","/ramdisk/couch/etc/couchdb/local.ini"]]},{'EXIT',{{badmatch,{error,shutdown}},[{couch_server_sup,start_server,1,[{file,"couch_server_sup.erl"},{line,98}]},{application_master,start_it_old,4,[{file,"application_master.erl"},{line,274}]}]}},[{couch,start,0,[{file,"couch.erl"},{line,18}]},{init,start_it,1,[]},{init,start_em,1,[]}]}}
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (COUCHDB-2298) 1.6.0 crashes on startup if plain (non-hashed) admins are present in .ini / config files

[Dave Cottlehuber (JIRA)]

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

Dave Cottlehuber updated COUCHDB-2298:
--

Fix Version/s: 1.6.1

> 1.6.0 crashes on startup if plain (non-hashed) admins are present in .ini / 
> config files
> 
>
> Key: COUCHDB-2298
> URL: https://issues.apache.org/jira/browse/COUCHDB-2298
> Project: CouchDB
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Database Core
>    Reporter: Dave Cottlehuber
>    Assignee: Dave Cottlehuber
> Fix For: 1.6.1
>
>
> If a couchdb install is managed via e.g. chef or similar, and the admin 
> passwords are pushed as plaintext, couchdb will crash on startup.
> {code}
> 1> Apache CouchDB 1.6.0 (LogLevel=info) is starting.
> {"init terminating in do_boot",{{badmatch,{error,{bad_return, 
> {{couch_app,start,[normal,["/ramdisk/couch/etc/couchdb/default.ini","/ramdisk/couch/etc/couchdb/local.ini"]]},{'EXIT',{{badmatch,{error,shutdown}},[{couch_server_sup,start_server,1,[{file,"couch_server_sup.erl"},{line,98}]},{application_master,start_it_old,4,[{file,"application_master.erl"},{line,274}]}]}},[{couch,start,0,[{file,"couch.erl"},{line,18}]},{init,start_it,1,[]},{init,start_em,1,[]}]}}
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (COUCHDB-2298) 1.6.0 crashes on startup if plain (non-hashed) admins are present in .ini / config files

[Dave Cottlehuber (JIRA)]

Dave Cottlehuber created COUCHDB-2298:
-

 Summary: 1.6.0 crashes on startup if plain (non-hashed) admins are 
present in .ini / config files
 Key: COUCHDB-2298
 URL: https://issues.apache.org/jira/browse/COUCHDB-2298
 Project: CouchDB
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: Database Core
Reporter: Dave Cottlehuber


If a couchdb install is managed via e.g. chef or similar, and the admin 
passwords are pushed as plaintext, couchdb will crash on startup.

{code}
1> Apache CouchDB 1.6.0 (LogLevel=info) is starting.
{"init terminating in do_boot",{{badmatch,{error,{bad_return, 
{{couch_app,start,[normal,["/ramdisk/couch/etc/couchdb/default.ini","/ramdisk/couch/etc/couchdb/local.ini"]]},{'EXIT',{{badmatch,{error,shutdown}},[{couch_server_sup,start_server,1,[{file,"couch_server_sup.erl"},{line,98}]},{application_master,start_it_old,4,[{file,"application_master.erl"},{line,274}]}]}},[{couch,start,0,[{file,"couch.erl"},{line,18}]},{init,start_it,1,[]},{init,start_em,1,[]}]}}
{code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (COUCHDB-2298) 1.6.0 crashes on startup if plain (non-hashed) admins are present in .ini / config files

[Dave Cottlehuber (JIRA)]

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

Dave Cottlehuber reassigned COUCHDB-2298:
-

Assignee: Dave Cottlehuber

> 1.6.0 crashes on startup if plain (non-hashed) admins are present in .ini / 
> config files
> 
>
> Key: COUCHDB-2298
> URL: https://issues.apache.org/jira/browse/COUCHDB-2298
> Project: CouchDB
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Database Core
>    Reporter: Dave Cottlehuber
>    Assignee: Dave Cottlehuber
>
> If a couchdb install is managed via e.g. chef or similar, and the admin 
> passwords are pushed as plaintext, couchdb will crash on startup.
> {code}
> 1> Apache CouchDB 1.6.0 (LogLevel=info) is starting.
> {"init terminating in do_boot",{{badmatch,{error,{bad_return, 
> {{couch_app,start,[normal,["/ramdisk/couch/etc/couchdb/default.ini","/ramdisk/couch/etc/couchdb/local.ini"]]},{'EXIT',{{badmatch,{error,shutdown}},[{couch_server_sup,start_server,1,[{file,"couch_server_sup.erl"},{line,98}]},{application_master,start_it_old,4,[{file,"application_master.erl"},{line,274}]}]}},[{couch,start,0,[{file,"couch.erl"},{line,18}]},{init,start_it,1,[]},{init,start_em,1,[]}]}}
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [REQUEST] Binaries for1.6.1-rc.3

[Dave Cottlehuber]

> Dear community, 
>  
> This is a request to prepare binaries for the 1.6.1-rc.3 release.  
>  
> Please follow the release procedure:  
>  
> http://wiki.apache.org/couchdb/Release_Procedure#Preparing_the_Binary_Packages
>   
>  
> Everyone is welcome to prepare binaries for this release.  
>  
> A+  
> Dave

Windows x86 R14B04 now up at:

https://dist.apache.org/repos/dist/dev/couchdb/binary/win/1.6.1/rc.3/

If building Erlang OTP 17.1 goes OK, I’ll post that too later on.

A+
Dave

[REQUEST] Binaries for1.6.1-rc.3

[Dave Cottlehuber]

Dear community,

This is a request to prepare binaries for the 1.6.1-rc.3 release.

Please follow the release procedure:

    
http://wiki.apache.org/couchdb/Release_Procedure#Preparing_the_Binary_Packages

Everyone is welcome to prepare binaries for this release.

A+
Dave

[jira] [Commented] (COUCHDB-2296) Possible non-free software included

[Dave Cottlehuber (JIRA)]

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

Dave Cottlehuber commented on COUCHDB-2296:
---

I emailed the author and asked if the terms can be clarified. In the event I 
need some Japanese assistance I know who to ask :-).

> Possible non-free software included
> ---
>
> Key: COUCHDB-2296
> URL: https://issues.apache.org/jira/browse/COUCHDB-2296
> Project: CouchDB
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: Harlan Lieberman-Berg
>
> Hello,
> I'm writing in regards to Debian Bug 
> [#758558|https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758558].  It seems 
> that the file share/www/script/base64.js is licensed under terms that are 
> vague enough to perhaps be unenforceable.  The license matches no known open 
> source license, and though the authors intent is clear to open source it to 
> some extent, the question is with what restrictions.  Defining it as "free" 
> is not enough to meet the DFSG requirements in my mind, and I wanted to raise 
> it to your attention in the case that it doesn't match yours either.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [VOTE] Release Apache CouchDB 1.6.1-rc.3

[Dave Cottlehuber]

> Dear community,
>
> I would like to release Apache CouchDB 1.6.1-rc.3.

+1 

sig, sha, md5, distcheck, verify install OK 

Debian Wheezy 7.6 amd64 backports 
- OTP R15B01 
- Spidermonkey 1.8.5 

FreeBSD 10.0-STABLE amd64 
- OTP 17.1 
- Spidermonkey 1.8.5 

A+ 
Dave 

[VOTE] Release Apache CouchDB 1.6.1-rc.3

[Dave Cottlehuber]

Dear community,

I would like to release Apache CouchDB 1.6.1-rc.3.

Changes since last round:

 * ensuring that the tarball & git branch I built from are one and the same 
(sorry)
 * ensuring that the official branch contains the required patch commit (sorry 
again)
 * 
https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=shortlog;h=refs/heads/1.6.x

We encourage the whole community to download and test these release artefacts 
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!

The release artefacts we are voting on are available here:

    wget 
https://dist.apache.org/repos/dist/dev/couchdb/source/1.6.1/rc.3/apache-couchdb-1.6.1.tar.gz
    wget 
https://dist.apache.org/repos/dist/dev/couchdb/source/1.6.1/rc.3/apache-couchdb-1.6.1.tar.gz.asc
    wget 
https://dist.apache.org/repos/dist/dev/couchdb/source/1.6.1/rc.3/apache-couchdb-1.6.1.tar.gz.ish
    wget 
https://dist.apache.org/repos/dist/dev/couchdb/source/1.6.1/rc.3/apache-couchdb-1.6.1.tar.gz.md5
    wget 
https://dist.apache.org/repos/dist/dev/couchdb/source/1.6.1/rc.3/apache-couchdb-1.6.1.tar.gz.sha

Please follow the test procedure here:

    http://wiki.apache.org/couchdb/Test_procedure

Please remember that "rc.3" is an annotation. If the vote passes, these 
artefacts will be released as Apache CouchDB 1.6.1.

Please cast your votes now.

Thanks,
— 
Dave Cottlehuber
d...@jsonified.com
Sent from my Couch

Re: [VOTE] Release Apache CouchDB 1.6.1-rc.2

[Dave Cottlehuber]

 
> Dear community,
>  
> I would like to release Apache CouchDB 1.6.1-rc.2.  
>  
> Changes since last round:  
>  
> * 1.6.0 + single patch for ensuring admins in local config are upgraded 
> correctly on restart  
> https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=shortlog;h=refs/heads/1.6.x
>  for details
>  
> We encourage the whole community to download and test these release artefacts 
> 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!  
>  
> The release artefacts we are voting on are available here:  
>  
> wget 
> https://dist.apache.org/repos/dist/dev/couchdb/source/1.6.1/rc.2/apache-couchdb-1.6.1.tar.gz
>   
> wget 
> https://dist.apache.org/repos/dist/dev/couchdb/source/1.6.1/rc.2/apache-couchdb-1.6.1.tar.gz.asc
> wget 
> https://dist.apache.org/repos/dist/dev/couchdb/source/1.6.1/rc.2/apache-couchdb-1.6.1.tar.gz.ish
> wget 
> https://dist.apache.org/repos/dist/dev/couchdb/source/1.6.1/rc.2/apache-couchdb-1.6.1.tar.gz.md5
> wget 
> https://dist.apache.org/repos/dist/dev/couchdb/source/1.6.1/rc.2/apache-couchdb-1.6.1.tar.gz.sha
>  
> Please follow the test procedure here:  
>  
> http://wiki.apache.org/couchdb/Test_procedure  
>  
> Please remember that "rc.2" is an annotation. If the vote passes, these 
> artefacts will be released as Apache CouchDB 1.6.1.  
>  
> Please cast your votes now.  
>  
> Thanks,  
> Dave

 I need to abort this one. Shortest RC lifespan ever. Sorry about that. 

[VOTE] Release Apache CouchDB 1.6.1-rc.2

[Dave Cottlehuber]

Dear community,

I would like to release Apache CouchDB 1.6.1-rc.2.

Changes since last round:

 * 1.6.0 + single patch for ensuring admins in local config are upgraded 
correctly on restart
   
https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=shortlog;h=refs/heads/1.6.x
 for details

We encourage the whole community to download and test these release artefacts 
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!

The release artefacts we are voting on are available here:

    wget 
https://dist.apache.org/repos/dist/dev/couchdb/source/1.6.1/rc.2/apache-couchdb-1.6.1.tar.gz
    wget 
https://dist.apache.org/repos/dist/dev/couchdb/source/1.6.1/rc.2/apache-couchdb-1.6.1.tar.gz.asc
    wget 
https://dist.apache.org/repos/dist/dev/couchdb/source/1.6.1/rc.2/apache-couchdb-1.6.1.tar.gz.ish
    wget 
https://dist.apache.org/repos/dist/dev/couchdb/source/1.6.1/rc.2/apache-couchdb-1.6.1.tar.gz.md5
    wget 
https://dist.apache.org/repos/dist/dev/couchdb/source/1.6.1/rc.2/apache-couchdb-1.6.1.tar.gz.sha

Please follow the test procedure here:

    http://wiki.apache.org/couchdb/Test_procedure

Please remember that "rc.2" is an annotation. If the vote passes, these 
artefacts will be released as Apache CouchDB 1.6.1.

Please cast your votes now.

Thanks,
Dave

[jira] [Updated] (COUCHDB-2295) Connection hangs on document update for multipart/related and transfer encoding chunked request

[Dave Cottlehuber (JIRA)]

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

Dave Cottlehuber updated COUCHDB-2295:
--

Fix Version/s: 1.7.0

> Connection hangs on document update for multipart/related and transfer 
> encoding chunked request
> ---
>
> Key: COUCHDB-2295
> URL: https://issues.apache.org/jira/browse/COUCHDB-2295
> Project: CouchDB
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: HTTP Interface
>Reporter: Alexander Shorin
> Fix For: 1.7.0
>
>
> Script to reproduce:
> {code}
> import pprint
> import requests
> body = [
> b'--996713c691ec4fd5b717ef2740893b78\r\n',
> b'Content-Type: application/json\r\n',
> b'\r\n',
> b'{"_id": "test","_attachments": {"foo": {"follows": true, 
> "content_type": "text/plain", "length": 12}}}\r\n',
> b'--996713c691ec4fd5b717ef2740893b78\r\n',
> b'Content-Type: text/plain\r\n'
> b'Content-Disposition: attachment;filename="foo"\r\n'
> b'Content-Length: 12\r\n'
> b'\r\n',
> b'Time to Relax!',
> b'--996713c691ec4fd5b717ef2740893b78--\r\n'
> ]
> url = 'http://localhost:5984/db/test'
> headers = {
> 'Content-Type': 'multipart/related; 
> boundary="996713c691ec4fd5b717ef2740893b78"'
> }
> resp = requests.put(url, headers=headers, data=iter(body))
> pprint.pprint(resp.json())
> {code}
> This runs a request:
> {code}
> PUT /db/test HTTP/1.1
> Host: localhost:5984
> Accept-Encoding: gzip, deflate
> Transfer-Encoding: chunked
> User-Agent: python-requests/2.3.0 CPython/3.4.1 Linux/3.15.5-gentoo
> Accept: */*
> Content-Type: multipart/related; boundary="996713c691ec4fd5b717ef2740893b78"
> 24
> --996713c691ec4fd5b717ef2740893b78
> 20
> Content-Type: application/json
> 2
> 68
> {"_id": "test","_attachments": {"foo": {"follows": true, "content_type": 
> "text/plain", "length": 14}}}
> 24
> --996713c691ec4fd5b717ef2740893b78
> 60
> Content-Type: text/plain
> Content-Disposition: attachment;filename="foo"
> Content-Length: 12
> e
> Time to Relax!
> 26
> --996713c691ec4fd5b717ef2740893b78--
> 0
> {code}
> But connection hangs: CouchDB thinks that there have to more data while zero 
> length chunk had been send and doesn't reply with anything back to client 
> which had finished the request and awaits for the response.
> The problem could be "fixed" by specifying full Content-Length of multipart 
> body in request, which kills all the idea of chunked transfer.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [VOTE] Release Apache CouchDB 1.6.1-rc.1

[Dave Cottlehuber]

Putting my pointy RM hat on I hereby abort the vote for this rc.

I think the best thing here is for me to unwind the 1.6.x branch,
cherry pick just the single fix in, and re-do a 1.6.1 as originally
planned.

— 
Dave Cottlehuber
d...@jsonified.com
Sent from my Couch

Re: [VOTE] Release Apache CouchDB 1.6.1-rc.1

[Dave Cottlehuber]

 
> Hi Dave,  
>  
> thanks for taking care of this!  
>  
> I saw that some features, e.g. "Add Experimental  
> Content-Security-Policy-Support (CSP)" and the "heartbeat interval" were  
> added to this release.  

Hi Robert,

I’m +0 either way. TBH I had called it 1.6.1 before digging in an
extracting a list of changes… I’ll add this to the release process
to check this before rolling tarballs about the internet!

- hb interval is a bugfix, but it does change the behaviour
- csp I see your point

> I might be wrong, I think that according to semver this would raise the
> version number to 1.7 , http://semver.org/ says: "Given a version number
> MAJOR.MINOR.PATCH, increment the: [...] MINOR version when you add
> functionality in a backwards-compatible manner."
>  
> What do you think?
>  
> Best,
> Robert

Let’s see what others think.

A+
Dave

Re: [VOTE] Release Apache CouchDB 1.6.1-rc.1

[Dave Cottlehuber]

+1

sig, sha, mg5, distcheck OK

Debian Wheezy 7.6 amd64 backports 
- OTP R15B01
- Spidermonkey 1.8.5


FreeBSD 10.0-STABLE amd64
- OTP 17.1
- Spidermonkey 1.8.5

A+
Dave