Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 832E47AE0 for ; Mon, 10 Oct 2011 22:21:12 +0000 (UTC) Received: (qmail 18902 invoked by uid 500); 10 Oct 2011 22:21:12 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 18875 invoked by uid 500); 10 Oct 2011 22:21:12 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 18867 invoked by uid 99); 10 Oct 2011 22:21:12 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Oct 2011 22:21:12 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of fdmanana@gmail.com designates 209.85.216.52 as permitted sender) Received: from [209.85.216.52] (HELO mail-qw0-f52.google.com) (209.85.216.52) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Oct 2011 22:21:05 +0000 Received: by qadz2 with SMTP id z2so6963171qad.11 for ; Mon, 10 Oct 2011 15:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=6nJqNhppVgwXlpFuKB0u20RzfZ20FArvuq+pKR7LOss=; b=m06rBiWcFmc2ShzHe/Ri0L/wORoo281Uq61C4MuZSZwovZEWr/Gm6Np6OmmgVsbkmo cN6g6Xg87MUPH2dMp362dxpwW/wdjFVqSzx8npAXoXxQBqHGhRCdVAfDju006t5/GWyO h6Atwun672MFnDA7axFNMg67nv74V05S7nq3s= MIME-Version: 1.0 Received: by 10.68.37.97 with SMTP id x1mr2221882pbj.14.1318285244019; Mon, 10 Oct 2011 15:20:44 -0700 (PDT) Sender: fdmanana@gmail.com Received: by 10.142.242.6 with HTTP; Mon, 10 Oct 2011 15:20:43 -0700 (PDT) In-Reply-To: References: Date: Mon, 10 Oct 2011 23:20:43 +0100 X-Google-Sender-Auth: pXGh4pn_7V-TUPMeW0hK996yDwA Message-ID: Subject: Re: CouchDB 1.1.1 From: Filipe David Manana To: dev@couchdb.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Mon, Oct 10, 2011 at 9:48 PM, Robert Newson wrote: > It's not just oauth_rsa_sha1.erl; > > ./oauth_http.erl:13: Warning: http:request/4 is deprecated and will be > removed in R15B; use httpc:request/4 Yep, mentioned it before, that one is apparently harmless since we don't trigger that codepath in CouchDB. > > B. > > > On 7 October 2011 18:42, Filipe David Manana wrote: >> Regarding the erlang-oauth and R15 compatibility, >> >> The compilation warnings only happen in the 1.1.x because >> src/erlang-oauth/Makefile.am is compiling oauth_rsa_sha1.erl while >> trunk and 1.2.x are not. >> >> Our OAuth handler is not supporting rsa-sha1 signatures, so it can be >> safely ignored. I think the right thing would be to exclude that file >> from the build list. >> >> It was added in the following 1.1.x commit: >> >> https://github.com/apache/couchdb/commit/ea57780780730eb5f2d98f30697e6a8= c2b3cf7f7 >> >> That said, upgrading to the same erlang-oauth we have in trunk/1.2.x won= 't help. >> >> On Thu, Oct 6, 2011 at 7:10 PM, Filipe David Manana wrote: >>> On Thu, Oct 6, 2011 at 6:59 PM, Robert Newson wrot= e: >>>> does the newer erlang-oauth break anything? >>> >>> Not that I know of. >>> >>>> >>>> On 6 October 2011 18:52, Filipe David Manana wro= te: >>>>> On Thu, Oct 6, 2011 at 6:23 PM, Robert Newson wr= ote: >>>>>> If there are no objections, I'm going to build the first 1.1.1 >>>>>> candidate in the morning and start a new thread for the release. >>>>> >>>>> As pointed out in 2 other related threads, we have some compilation >>>>> warnings about functions that will no longer exist in OTP R15 (to be >>>>> released by the end of this year): >>>>> >>>>> /opt/r14b03/bin/erlc +debug_info oauth_http.erl >>>>> ./oauth_http.erl:13: Warning: http:request/4 is deprecated and will b= e >>>>> removed in R15B; use httpc:request/4 >>>>> /opt/r14b03/bin/erlc +debug_info oauth_plaintext.erl >>>>> /opt/r14b03/bin/erlc +debug_info oauth_rsa_sha1.erl >>>>> ./oauth_rsa_sha1.erl:9: Warning: public_key:pem_to_der/1: deprecated >>>>> (will be removed in R15A); use file:read_file/1 and >>>>> public_key:pem_decode/1 >>>>> ./oauth_rsa_sha1.erl:10: Warning: public_key:decode_private_key/1 is >>>>> deprecated and will be removed in R15A; use >>>>> public_key:pem_entry_decode/1 >>>>> ./oauth_rsa_sha1.erl:22: Warning: public_key:pem_to_der/1: deprecated >>>>> (will be removed in R15A); use file:read_file/1 and >>>>> public_key:pem_decode/1 >>>>> /opt/r14b03/bin/erlc +debug_info oauth_unix.erl >>>>> >>>>> The ones regarding public_key concern me, as it will break the OAuth >>>>> authentication handler. >>>>> I see 2 solutions: >>>>> >>>>> 1) upgrade erlang-oauth to the same version we have in trunk/1.2.x >>>>> (doesn't produce these warnings) >>>>> >>>>> 2) modify the erlang-oauth in 1.1.x and use try catches where the >>>>> catch would call the equivalent versions in R14/R15 (these new >>>>> functions don't exist in R13B03 for example) >>>>> >>>>> Naturally, I would prefer 1) >>>>> >>>>> The warnings about http:request can be ignored I think, as in Couch w= e >>>>> don't use any codepath that will execute the deprecated function >>>>> >>>>>> >>>>>> B. >>>>>> >>>>>> On 6 October 2011 12:05, Robert Newson wrote: >>>>>>> Thanks all, I've pushed the change to 1.1.x. make check and futon a= ll >>>>>>> pass; review would still be nice. :) I simply reverted the two >>>>>>> commits. >>>>>>> >>>>>>> B. >>>>>>> >>>>>>> On 6 October 2011 12:02, Jan Lehnardt wrote: >>>>>>>> >>>>>>>> On Oct 6, 2011, at 10:30 , Robert Newson wrote: >>>>>>>> >>>>>>>>> There is no build of 1.1.1 on Ubuntu 11.x that will work as well = as >>>>>>>>> 1.1.0, so I think it's correct that it cannot build under those >>>>>>>>> conditions. >>>>>>>>> >>>>>>>>> Let's get 1.1.1 out, with the many useful bug fixes and tweaks, a= nd >>>>>>>>> then focus on getting 1.2 out with 1.8.5 support (and "BREAKING >>>>>>>>> CHANGES"). >>>>>>>>> >>>>>>>>> I vote +1 to removing 1.8.5 support and the paren hack from 1.1.x= . >>>>>>>> >>>>>>>> +1 >>>>>>>> >>>>>>>> Cheers >>>>>>>> Jan >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> B. >>>>>>>>> >>>>>>>>> On 6 October 2011 09:25, Paul Davis = wrote: >>>>>>>>>> On Thu, Oct 6, 2011 at 3:23 AM, Robert Newson wrote: >>>>>>>>>>> All, >>>>>>>>>>> >>>>>>>>>>> Paul Davis has researched the issue and it seems intractable. >>>>>>>>>>> >>>>>>>>>>> I would like to remove 1.8.5 support from 1.1.1. It was not pre= sent in >>>>>>>>>>> 1.1.0 so will not be (officially) missed. >>>>>>>>>>> >>>>>>>>>>> The place for a breaking change of this magnitude is 1.2, not a= minor >>>>>>>>>>> bug fix release. >>>>>>>>>>> >>>>>>>>>>> Thoughts? >>>>>>>>>>> B. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> +1 on removing the paren hack for sure. >>>>>>>>>> >>>>>>>>>> Not sure about removing 1.8.5 support completely. On the one han= d, it >>>>>>>>>> would prevent breakage because people couldn't link against the >>>>>>>>>> breaking SM. On the other hand, it prevents people from linking >>>>>>>>>> against 1.8.5 which means it won't build on Ubuntu 11.x. >>>>>>>>>> >>>>>>>>>> Unless someone comes up with a magic option I'd say put it to an >>>>>>>>>> informal vote so that I can blame someone else. >>>>>>>>>> >>>>>>>>>>> On 5 October 2011 18:25, Paul Davis wrote: >>>>>>>>>>>> Yes, its release blocking. >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Oct 5, 2011 at 7:56 AM, Robert Newson wrote: >>>>>>>>>>>>> All, >>>>>>>>>>>>> >>>>>>>>>>>>> I went through JIRA and updated CHANGES and NEWS on origin/1.= 1.x to >>>>>>>>>>>>> include everything that was missing (Sidenote: Can we all kee= p this >>>>>>>>>>>>> file up to date when commit bugfixes or add features?). I'd a= ppreciate >>>>>>>>>>>>> everyone giving it a look over before I start to build the re= lease >>>>>>>>>>>>> artifact. >>>>>>>>>>>>> >>>>>>>>>>>>> I believe there's an outstanding issue (not present in JIRA) = around >>>>>>>>>>>>> javascript function evaluation? Can someone confirm that it's= release >>>>>>>>>>>>> blocking? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> B. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Filipe David Manana, >>>>> >>>>> "Reasonable men adapt themselves to the world. >>>>> =C2=A0Unreasonable men adapt the world to themselves. >>>>> =C2=A0That's why all progress depends on unreasonable men." >>>>> >>>> >>> >>> >>> >>> -- >>> Filipe David Manana, >>> >>> "Reasonable men adapt themselves to the world. >>> =C2=A0Unreasonable men adapt the world to themselves. >>> =C2=A0That's why all progress depends on unreasonable men." >>> >> >> >> >> -- >> Filipe David Manana, >> >> "Reasonable men adapt themselves to the world. >> =C2=A0Unreasonable men adapt the world to themselves. >> =C2=A0That's why all progress depends on unreasonable men." >> > --=20 Filipe David Manana, "Reasonable men adapt themselves to the world. =C2=A0Unreasonable men adapt the world to themselves. =C2=A0That's why all progress depends on unreasonable men."