[DRE-maint] Bug#869070: apt-listbugs does not honor Acquire::http::TimeOut

[Francesco Poli]

Control: reassign -1 ruby-soap4r 2.0.5-3
Control: affects -1 + apt-listbugs



On Tue, 1 Aug 2017 23:27:17 +0200 Francesco Poli wrote:

[...]
> On Tue, 1 Aug 2017 10:34:00 +0200 Vincent Lefevre wrote:
> 
> > On 2017-08-01 10:24:13 +0200, Vincent Lefevre wrote:
> > > This solves the timeout issue, but actually the bug is worse than
> > > I thought. After setting
> > > 
> > >         @drv.options["protocol.http.connect_timeout"] = 10
> > >         @drv.options["protocol.http.send_timeout"] = 10
> > >         @drv.options["protocol.http.receive_timeout"] = 10
> > > 
> > > I get:
> > > 
> > > Retrieving bug reports... 0% Fail
> > > Error retrieving bug reports from the server with the following error message:
> > > E: execution expired
> > > It could be because your network is down, or because of broken proxy servers, or the BTS server itself is down. Check network configuration and try again
> > > Retry downloading bug information? [Y/n] 
> > > 
> > > i.e. it doesn't fallback to the IPv4 address, contrary to what
> > > other tools do!
> > 
> > Well, without the above change, I get the usual 2-minute timeout
> > per IP address, and the fallback to the first IP address that works
> > (here, IPv4). I assume that this is because the timeout occurs at
> > the socket level instead of the protocol level, thus not handled
> > by the same code.
> 
> Then the situation is less easy than I was hoping...

Hello Debian Ruby Extras Maintainers,
I am reassigning a [bug report] filed against package apt-listbugs,
where the submitter (Vincent) would like to be able to configure the
SOAP http timeout, in order to shorten his wait for the fallback to the
first IP address that works.

[bug report]: <https://bugs.debian.org/869070>

Unfortunately, from a test that I suggested, it turned out that setting
the protocol.http.* timeout options for ruby-soap4r does not cause the
expected behavior.

During my summer vacations (and after them), I made some attempts to
search for documentation about these ruby-soap4r timeout, but I failed
to find a clear explanation of what actually happens when one of these
timeouts is reached.

Hence, I am asking to you: why does the described behavior (see the bug
log) happen? should ruby-soap4r behave as Vincent expected?

Please clarify and/or fix the ruby-soap4r behavior and/or forward this
bug report upstream.
Thanks for your time!

Bye.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-ruby-extras-maintainers/attachments/20170908/f184f42e/attachment.sig>