This is a multi-part message in MIME format.
On 2025-07-19 06:47, Francesco Poli wrote:
Control: tags -1 moreinfo
On Fri, 18 Jul 2025 18:23:29 +1000 Cameron Davidson wrote:
Package: apt-listbugs
Version: 0.1.47
Severity: normal
Tags: ipv6
Dear Maintainer,
Hello Cameron,
thanks for your bug report.
Thanks for the detailed response
* Verified in Debian 12 as well as Deb 13 testing.
If apt-listbugs is installed in a system then, when there are problems
with IPv6, "apt install/update" can appear to hang at
"Retrieving bug reports...0%"
Requires ctrl-C, and after saying do not try to retrieve bugs again
apt asks if it should continue installation.
When I select "yes" it then fails to continue installation.
This looks like a [known issue] with the dash shell, which, as far as I
can tell, is still used by libapt to invoke hooks. I have [repeatedly] [asked] the APT Development Team for a status update on this issue, but I haven't yet received any reply...
[known issue]:<https://bugs.debian.org/832593#80> [repeatedly]:<https://bugs.debian.org/960442#15> [asked]:<https://bugs.debian.org/960442#37>
Also "apt-listbugs -d list apt-listbugs" initally reports:
Exception `LoadError' at <internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:136 - cannot load such file -- soap/rpc/driver
Exception `LoadError' at <internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:136 - cannot load such file -- xml/encoding-ja
Exception `LoadError' at <internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:144 - cannot load such file -- xml/encoding-ja
Set XSD::XMLParser::XMLParser as XML processor.
Exception `LoadError' at <internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:136 - cannot load such file -- httpclient
Exception `LoadError' at <internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:136 - cannot load such file -- addressable/uri
Exception `LoadError' at <internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:144 - cannot load such file -- addressable/uri
Exception `KeyError' at /usr/lib/ruby/vendor_ruby/http/cookie_jar/abstract_store.rb:15 - key not found: :hash
Well, this is debug output coming from the Ruby library (I think).
You cannot expect a perfectly clean and beautiful output, when you pass
the debug option... ;-)
I did not know what to expect, not having ruby installed until apt-listbugs.
I was just following instructions that had been given in other bug reports.
and then gets to...
"! CONNECT TO bugs.debian.org 80" (Debian 12)
at which point it seems to hang. But if I wait for
over 6 MINUTES then it does seem to fall back to IPv4 to get the details.
Over 6 min, you say?
How much more than 6 min?
Using the "time ..." command it reported as 6min 45 seconds for Debian
13, and 6min plus somewhere between 20 and 30 s for Debian 12.
Could it be almost 17 min, by chance?
The only [timeout] set by apt-listbugs itself is 999 s long (which corresponds to almost 17 min), for the SOAP connection.
[timeout]:<https://salsa.debian.org/frx-guest/apt-listbugs/-/blob/f9053c84c6cd3ab30556bea10a44ca64a929d3b0/lib/aptlistbugs/debian/btssoap.rb#L38>
This was changed almost [19 years ago], before I began to maintain and develop apt-listbugs. And it seems it was done in response to a bug
report...
[19 years ago]:<https://salsa.debian.org/frx-guest/apt-listbugs/-/commit/481b5e6e7adc3d557d17d3ed471c4f78e126c0e0>
If there's another timeout that kicks in before 999 s at about 360 s or
so, I cannot understand where it is coming from, to be honest.
I haven't found any default timeout set by [ruby-soap4r], apart from
the ones that apt-listbugs sets to 999 s ...
[ruby-soap4r]:<https://salsa.debian.org/ruby-team/ruby-soap4r/-/tree/f60e60bbfaf557b1c7a2a42285d3d4349d0a6eef>
And the default timeout for [ruby-httpclient] seems to be 60 s, if I understand correctly...
[ruby-httpclient]:<https://salsa.debian.org/ruby-team/ruby-httpclient/-/blob/d35b14cda69bbce6ab7e63ab7199c98d4d060a51/lib/httpclient/session.rb#L145>
I am really puzzled...
So perhaps my subject line is wrong, but the timeouts are obviously too
long and, coupled with the multiple redirects, means nobody is going to wait that
long unless they've gone off for a coffee.
You have to admit that the main purpose of the connection timeout is
not to fall back to IPv4, when IPv6 fails.
Moreover, it looks unfortunate that your IPv6 network makes the clients
wait indefinitely (until some timeout kicks in, I mean), rather than
failing with some immediate error...
IPv6 is fine on my system, even to the ISP's internal network, so I have
no way to know that the packets get lost on the way back.
Waiting for a timeout is my only option short of disabling IPv6 completely
The cause of the problem is that my ISP broke routing for my IPv6 address a >> week ago, but it was not immediately obvious and is still not fixed.
workaround: is to either uninstall apt-listbugs, or temporarily disable
IPv6 (if convenient). In either case apt then works quickly.
Well, if you remove apt-listbugs, you won't enjoy its services, of
course! ;-)
On the other hand, if you temporarily disable IPv6, you have to do
something inconvenient, whenever you want to use apt or aptitude...
I think that you could try to set another timeout
in /usr/lib/ruby/vendor_ruby/aptlistbugs/debian/btssoap.rb (lines 38,
39, and 40) and see whether your wait changes.
This way, we could perhaps check whether this is indeed the timeout
that kicks in. And whether reducing it helps your use case.
Please let me know, if you perform this test.
Thanks for your time and patience.
Sorry about the delay - I was just sitting down to run those checks for
you when the routing problem got fixed (a mere 8 days after reporting
it to my ISP).
It is probably a rare enough event that I don't feel inclined to
artificially adjust my firewall to simulate the situation again.
My guess about the delay is that maybe it is the accumulation of 60
second delays in each of 6 requests.
Thanks again,
Cameron.
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 2025-07-19 06:47, Francesco Poli
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:
[email protected]">
<pre wrap="" class="moz-quote-pre">Control: tags -1 moreinfo
On Fri, 18 Jul 2025 18:23:29 +1000 Cameron Davidson wrote:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">Package: apt-listbugs
Version: 0.1.47
Severity: normal
Tags: ipv6
Dear Maintainer,
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
Hello Cameron,
thanks for your bug report.</pre>
</blockquote>
<br>
<p>Thanks for the detailed response</p>
<p><span style="white-space: pre-wrap">
</span></p>
<p><span style="white-space: pre-wrap">
</span></p>
<blockquote type="cite"
cite="mid:
[email protected]">
<pre wrap="" class="moz-quote-pre">
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">
* Verified in Debian 12 as well as Deb 13 testing.
If apt-listbugs is installed in a system then, when there are problems
with IPv6, "apt install/update" can appear to hang at
"Retrieving bug reports...0%"
Requires ctrl-C, and after saying do not try to retrieve bugs again
apt asks if it should continue installation.
When I select "yes" it then fails to continue installation.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
This looks like a [known issue] with the dash shell, which, as far as I
can tell, is still used by libapt to invoke hooks. I have [repeatedly]
[asked] the APT Development Team for a status update on this issue, but I haven't yet received any reply...
[known issue]: <a class="moz-txt-link-rfc2396E" href="
https://bugs.debian.org/832593#80"><https://bugs.debian.org/832593#80></a>
[repeatedly]: <a class="moz-txt-link-rfc2396E" href="
https://bugs.debian.org/960442#15"><https://bugs.debian.org/960442#15></a>
[asked]: <a class="moz-txt-link-rfc2396E" href="
https://bugs.debian.org/960442#37"><https://bugs.debian.org/960442#37></a>
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">
Also "apt-listbugs -d list apt-listbugs" initally reports:
Exception `LoadError' at <internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:136 - cannot load such file -- soap/rpc/driver
Exception `LoadError' at <internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:136 - cannot load such file -- xml/encoding-ja
Exception `LoadError' at <internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:144 - cannot load such file -- xml/encoding-ja
Set XSD::XMLParser::XMLParser as XML processor.
Exception `LoadError' at <internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:136 - cannot load such file -- httpclient
Exception `LoadError' at <internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:136 - cannot load such file -- addressable/uri
Exception `LoadError' at <internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:144 - cannot load such file -- addressable/uri
Exception `KeyError' at /usr/lib/ruby/vendor_ruby/http/cookie_jar/abstract_store.rb:15 - key not found: :hash
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
Well, this is debug output coming from the Ruby library (I think).
You cannot expect a perfectly clean and beautiful output, when you pass
the debug option... ;-)</pre>
</blockquote>
<p>I did not know what to expect, not having ruby installed until
apt-listbugs.<br>
</p>
<p>I was just following instructions that had been given in other
bug reports.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:
[email protected]">
<pre wrap="" class="moz-quote-pre">
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">
and then gets to...
"! CONNECT TO bugs.debian.org 80" (Debian 12)
at which point it seems to hang. But if I wait for
over 6 MINUTES then it does seem to fall back to IPv4 to get the details. </pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
Over 6 min, you say?
How much more than 6 min?</pre>
</blockquote>
<p>Using the "time ..." command it reported as 6min 45 seconds for
Debian 13, and 6min plus somewhere between 20 and 30 s for Debian
12.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:
[email protected]">
<pre wrap="" class="moz-quote-pre">
Could it be almost 17 min, by chance?
The only [timeout] set by apt-listbugs itself is 999 s long (which
corresponds to almost 17 min), for the SOAP connection.
[timeout]: <a class="moz-txt-link-rfc2396E" href="
https://salsa.debian.org/frx-guest/apt-listbugs/-/blob/f9053c84c6cd3ab30556bea10a44ca64a929d3b0/lib/aptlistbugs/debian/btssoap.rb#L38"><https://salsa.debian.org/frx-guest/apt-listbugs/-/blob/
f9053c84c6cd3ab30556bea10a44ca64a929d3b0/lib/aptlistbugs/debian/btssoap.rb#L38></a>
This was changed almost [19 years ago], before I began to maintain and
develop apt-listbugs. And it seems it was done in response to a bug
report...
[19 years ago]: <a class="moz-txt-link-rfc2396E" href="
https://salsa.debian.org/frx-guest/apt-listbugs/-/commit/481b5e6e7adc3d557d17d3ed471c4f78e126c0e0"><https://salsa.debian.org/frx-guest/apt-listbugs/-/commit/
481b5e6e7adc3d557d17d3ed471c4f78e126c0e0></a>
If there's another timeout that kicks in before 999 s at about 360 s or
so, I cannot understand where it is coming from, to be honest.
I haven't found any default timeout set by [ruby-soap4r], apart from
the ones that apt-listbugs sets to 999 s ...
[ruby-soap4r]: <a class="moz-txt-link-rfc2396E" href="
https://salsa.debian.org/ruby-team/ruby-soap4r/-/tree/f60e60bbfaf557b1c7a2a42285d3d4349d0a6eef"><https://salsa.debian.org/ruby-team/ruby-soap4r/-/tree/f60e60bbfaf557b1c7a2a42285d3d4349d0a6eef></
And the default timeout for [ruby-httpclient] seems to be 60 s, if I
understand correctly...
[ruby-httpclient]: <a class="moz-txt-link-rfc2396E" href="
https://salsa.debian.org/ruby-team/ruby-httpclient/-/blob/d35b14cda69bbce6ab7e63ab7199c98d4d060a51/lib/httpclient/session.rb#L145"><https://salsa.debian.org/ruby-team/ruby-httpclient/-/blob/
d35b14cda69bbce6ab7e63ab7199c98d4d060a51/lib/httpclient/session.rb#L145></a>
I am really puzzled...
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">
So perhaps my subject line is wrong, but the timeouts are obviously too
long and, coupled with the multiple redirects, means nobody is going to wait that
long unless they've gone off for a coffee.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
You have to admit that the main purpose of the connection timeout is
not to fall back to IPv4, when IPv6 fails.
Moreover, it looks unfortunate that your IPv6 network makes the clients
wait indefinitely (until some timeout kicks in, I mean), rather than
failing with some immediate error...</pre>
</blockquote>
<p><br>
</p>
<p>IPv6 is fine on my system, even to the ISP's internal network, so
I have no way to know that the packets get lost on the way back.</p>
<p>Waiting for a timeout is my only option short of disabling IPv6
completely<br>
</p>
<blockquote type="cite"
cite="mid:
[email protected]">
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">
The cause of the problem is that my ISP broke routing for my IPv6 address a week ago, but it was not immediately obvious and is still not fixed.
workaround: is to either uninstall apt-listbugs, or temporarily disable
IPv6 (if convenient). In either case apt then works quickly.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
Well, if you remove apt-listbugs, you won't enjoy its services, of
course! ;-)
On the other hand, if you temporarily disable IPv6, you have to do
something inconvenient, whenever you want to use apt or aptitude...
I think that you could try to set another timeout
in /usr/lib/ruby/vendor_ruby/aptlistbugs/debian/btssoap.rb (lines 38,
39, and 40) and see whether your wait changes.
This way, we could perhaps check whether this is indeed the timeout
that kicks in. And whether reducing it helps your use case.
Please let me know, if you perform this test.
Thanks for your time and patience.
</pre>
</blockquote>
<p>Sorry about the delay - I was just sitting down to run those
checks for you when the routing problem got fixed (a mere 8 days
after reporting it to my ISP).</p>
<p>It is probably a rare enough event that I don't feel inclined to
artificially adjust my firewall to simulate the situation again.</p>
<p>My guess about the delay is that maybe it is the accumulation of
60 second delays in each of 6 requests. <br>
</p>
<p>Thanks again,</p>
<p>Cameron.<br>
</p>
</body>
</html>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)