Patches for the ANONFUNFIX thing are attached to 1302 if someone wants to review and/or test right quick.
https://issues.apache.org/jira/browse/COUCHDB-1302 On Mon, Oct 10, 2011 at 5:22 PM, Robert Newson <[email protected]> wrote: > I backported erlang-oauth to 1.1.x from master and also fixed > etap_web.erl. no warnings now. > > B. > > On 10 October 2011 23:20, Filipe David Manana <[email protected]> wrote: >> On Mon, Oct 10, 2011 at 9:48 PM, Robert Newson <[email protected]> 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 <[email protected]> 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/ea57780780730eb5f2d98f30697e6a8c2b3cf7f7 >>>> >>>> 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 <[email protected]> >>>> wrote: >>>>> On Thu, Oct 6, 2011 at 6:59 PM, Robert Newson <[email protected]> wrote: >>>>>> does the newer erlang-oauth break anything? >>>>> >>>>> Not that I know of. >>>>> >>>>>> >>>>>> On 6 October 2011 18:52, Filipe David Manana <[email protected]> wrote: >>>>>>> On Thu, Oct 6, 2011 at 6:23 PM, Robert Newson <[email protected]> >>>>>>> wrote: >>>>>>>> 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 be >>>>>>> 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 we >>>>>>> don't use any codepath that will execute the deprecated function >>>>>>> >>>>>>>> >>>>>>>> B. >>>>>>>> >>>>>>>> On 6 October 2011 12:05, Robert Newson <[email protected]> wrote: >>>>>>>>> Thanks all, I've pushed the change to 1.1.x. make check and futon all >>>>>>>>> pass; review would still be nice. :) I simply reverted the two >>>>>>>>> commits. >>>>>>>>> >>>>>>>>> B. >>>>>>>>> >>>>>>>>> On 6 October 2011 12:02, Jan Lehnardt <[email protected]> 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, and >>>>>>>>>>> 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 <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>>> On Thu, Oct 6, 2011 at 3:23 AM, Robert Newson <[email protected]> >>>>>>>>>>>> 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 >>>>>>>>>>>>> present 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 hand, >>>>>>>>>>>> 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 <[email protected]> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> Yes, its release blocking. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Oct 5, 2011 at 7:56 AM, Robert Newson >>>>>>>>>>>>>> <[email protected]> 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 keep >>>>>>>>>>>>>>> this >>>>>>>>>>>>>>> file up to date when commit bugfixes or add features?). I'd >>>>>>>>>>>>>>> appreciate >>>>>>>>>>>>>>> everyone giving it a look over before I start to build the >>>>>>>>>>>>>>> release >>>>>>>>>>>>>>> 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. >>>>>>> Unreasonable men adapt the world to themselves. >>>>>>> That's why all progress depends on unreasonable men." >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Filipe David Manana, >>>>> >>>>> "Reasonable men adapt themselves to the world. >>>>> Unreasonable men adapt the world to themselves. >>>>> That's why all progress depends on unreasonable men." >>>>> >>>> >>>> >>>> >>>> -- >>>> Filipe David Manana, >>>> >>>> "Reasonable men adapt themselves to the world. >>>> Unreasonable men adapt the world to themselves. >>>> That's why all progress depends on unreasonable men." >>>> >>> >> >> >> >> -- >> Filipe David Manana, >> >> "Reasonable men adapt themselves to the world. >> Unreasonable men adapt the world to themselves. >> That's why all progress depends on unreasonable men." >> >
