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. > > * 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... ;-) > > 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? 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... > > > 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. -- 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
pgpVy_Y0C5yYs.pgp
Description: PGP signature
