[DRE-maint] Bug#881627: Congratulations AmazonShopper! Kr

[mario serna]

Stop emailing me

On Nov 14, 2017 12:08 PM, "AmazonReward Alert" <
debian.axhn at manchmal.in-ulm.de> wrote:

> Message for mario
>
>
> <http://lavishjob.com/cl/r-S5LNS7MEGC4S143KDS1CK7ISE3NS0S0S0S15S2SBSCCS21FS1GMSA>
>
>
> <http://lavishjob.com/cl/ua-S5LNS7MEGC4S143KDS1CK7ISE3NS0S0S0S15S2SBSCCS21FS1GMSA>
>
>
> <http://lavishjob.com/cl/op-S5LNS7MEGC4S143KDS1CK7ISE3NS0S0S0S15S2SBSCCS21FS1GMSA>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Source: ruby-http-parser.rb Version: 0.6.0-3+b3 Severity: serious Tags:
> upstream Dear Maintainer, your package build-depends on http-parser, and a
> new version of that one has been around for a while. Even before eventually
> uploading last night I already saw a problem in the test suite of your
> package. However, due to a fault on my side, the new http-parser went to
> unstable instead of experimental. So this increases the pressure for your
> package, sorry about that. With http-parser 2.7.1, one test fails: 1)
> HTTP::Parser should parse request: line folding in header value
> Failure/Error: expect(@headers).to eq(test) expected:
> {"Line1"=>"abcdefghijklmno qrs", "Line2"=>"line2\t"} got:
> {"Line1"=>"abc\tdef ghi\t\tjkl mno \t \tqrs", "Line2"=>"line2\t"} (compared
> using ==) Diff: @@ -1,3 +1,3 @@ -"Line1" => "abcdefghijklmno qrs", +"Line1"
> => "abc\tdef ghi\t\tjkl mno \t \tqrs", "Line2" => "line2\t", #
> ./spec/parser_spec.rb:347:in `block (4 levels) in ' If I understand
> correctly, this is taken from spec/support/requests.json line 445 and 457f.
> While doubtlessly http-parser changed the behaviour, I'm not sure yet
> whether this wasn't rather about fixing bugs - bugs the test in
> ruby-http-parser.rb relied upon. However, HTTP header line folding is
> complicated and actually also deprecated in RFC 7230. Reading that one and
> also the older description in RFC 2616 I guess there a too many freedoms to
> expect a certain result. Also it seems http-parser 2.7.1 does unfolding in
> a ... surprising manner. Now, quite frankly, my main interest is a sound
> solution. Otherwise, I'm not keen on legal discussions, especially when
> it's about a deprecated feature like this one. It's my job to sort these
> things out with http-parser upstream but since I'm not sure how long this
> will take: Would you mind disabling or relaxing the test on your side for
> the time being? You might as well upgrade the test to the one in
> http-parser/test.c¹ which is where obviously it was taken from in the first
> place - but I'd expect this to change again soon. Sorry for the mess, and
> kind regards, Christoph ¹ https://github.com/nodejs/http-parser/blob/master/test.c
> (line 614)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-ruby-extras-maintainers/attachments/20171114/5cda8340/attachment-0001.html>