On Sat, 10 Jan 2026 12:58:25 +0100 Vincent Lefevre wrote: > On 2026-01-09 23:37:15 +0100, Francesco Poli wrote: > > Do you have a reliable way to artificially obtain that error? > > No, but something that could be tried is to use the -u option > to send the request to another web server and see what error > would be obtained. I don't know whether a soap.cgi would be > needed for such a test server.
I had tried playing with the -u option, but, unfortunately, if nothing
is listening to the specified port, the error is different (as it is
reasonable):
$ apt-listbugs -u https://localhost:443/cgi-bin/soap.cgi list apt
Retrieving bug reports... 0% Fail
Error retrieving bug reports from the server with the following error
message:
E: Connection refused - Connection refused - connect(2) for "localhost"
port 443 (localhost:443)
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 am afraid that an actual SOAP server needs to listen to the
appropriate port of the test destination host.
But I don't know how to setup such server, and, above all, I have no
idea which kind of protocol error it should artificially inject into
the communication...
After all, you wish apt-listbugs gave more information, exactly because
we are trying to investigate this: what kind of stream error is
sporadically encountered, while interacting with the Debian BTS SOAP
interface.
If we already knew, there would be no point in investigating!
I am testing with apt-listbugs more often than usual, in the hope to
"naturally" encounter the error again...
--
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
pgpuDj1RkhI_L.pgp
Description: PGP signature
