Ubuntu
squid-deb-proxy package

python exceptions bleeding into stdout

Bug #1505670 reported by Rolf Leggewie on 2015-10-13

This bug affects 6 people

	Status	Importance	Assigned to
squid-deb-proxy (Ubuntu)	Fix Released	Low	Miriam España Acebal
Trusty	Won't Fix	Low	Unassigned
Xenial	Won't Fix	Low	Unassigned
Bionic	Fix Released	Low	Miriam España Acebal
Focal	Fix Released	Low	Miriam España Acebal
Hirsute	Fix Released	Low	Miriam España Acebal
Impish	Fix Released	Low	Miriam España Acebal

Bug Description

[Impact]

As @cell explains, the problem here is that the errors are going to stdout, not to stderr. This means apt's Acquire::http::ProxyAutoDetect is not able to figure out what the proxy URL is.

[Test Plan]

The idea is to create a VM with several interfaces, to cache them plus to check configuration and do the discovery. Here you can see the test for Focal, but it has been the same behaviour for Hirsute, Bionic and Impish.

Note: In comment #22 there's a very straightforward test (Impish) without the need for extra ifaces.

Steps to reproduce (thanks to @cpaelzer and @sergiodj):

  #0
  # On the test Host install apt-cacher-ng
  # you need to do so before creating the guest VM to propagate
  # and configure correctly when spawned
  $ sudo apt install apt-cacher-ng

  # 1
  # On the Host, create the IPv4 addresses and the VM. Stop the VM to
  # attach the ifaces and start again the VM to log in.

  $ for i in 1 2 3 4; do lxc network create testnet${i}; done
  $ lxc network list
  $ lxc launch ubuntu-daily:focal test-bug1505670-focal --vm
  $ lxc stop test-bug1505670-focal
  $ for i in 1 2 3 4; do lxc network attach testnet${i} test-bug1505670-focal; done
  $ lxc start test-bug1505670-focal
  $ lxc shell test-bug1505670-focal

  # Now at the VM, install prereq packages
  $ sudo apt update
  $ sudo apt install avahi-utils squid-deb-proxy-client

  #3
  # check if all are interfaces are configured
  $ ip a

# (you might need to edit netplan or E/N/I to e.g. dhcp on all of them) to have the following content (check the names of your interfaces from the 'ip a' command above and change them if needed):

$ vim /etc/netplan/50-cloud-init.yaml

  network:
     version: 2
     renderer: networked
     ethernet:
         enp5s0:
             dhcp4: true
         enp6s0:
             dhcp4: true
         enp7s0:
             dhcp4: true
         enp8s0:
             dhcp4: true
         enp09s0:
             dhcp4: true

#apply the changes to the ifaces:
$ sudo netplan apply

  # 4
  # avahi probes all ifaces
  $ avahi-browse -kprtf _apt_proxy._tcp
+;enp8s0;IPv6;apt-cacher-ng\032proxy\032on\032test-bug1505670-focal;_apt_proxy._tcp;local
+;enp8s0;IPv4;apt-cacher-ng\032proxy\032on\032test-bug1505670-focal;_apt_proxy._tcp;local
+;enp7s0;IPv6;apt-cacher-ng\032proxy\032on\032test-bug1505670-focal;_apt_proxy._tcp;local
+;enp7s0;IPv4;apt-cacher-ng\032proxy\032on\032test-bug1505670-focal;_apt_proxy._tcp;local
+;enp6s0;IPv6;apt-cacher-ng\032proxy\032on\032test-bug1505670-focal;_apt_proxy._tcp;local
+;enp6s0;IPv4;apt-cacher-ng\032proxy\032on\032test-bug1505670-focal;_apt_proxy._tcp;local
+;enp5s0;IPv6;apt-cacher-ng\032proxy\032on\032test-bug1505670-focal;_apt_proxy._tcp;local
+;enp5s0;IPv4;apt-cacher-ng\032proxy\032on\032test-bug1505670-focal;_apt_proxy._tcp;local
+;lo;IPv4;apt-cacher-ng\032proxy\032on\032test-bug1505670-focal;_apt_proxy._tcp;local
=;enp8s0;IPv6;apt-cacher-ng\032proxy\032on\032test-bug1505670-focal;_apt_proxy._tcp;local;test-bug1505670-focal.local;fd42:701b:b04:c7ab:216:3eff:feda:f1e7;3142;
=;enp8s0;IPv4;apt-cacher-ng\032proxy\032on\032test-bug1505670-focal;_apt_proxy._tcp;local;test-bug1505670-focal.local;10.8.60.155;3142;
=;enp7s0;IPv6;apt-cacher-ng\032proxy\032on\032test-bug1505670-focal;_apt_proxy._tcp;local;test-bug1505670-focal.local;fd42:3406:c5ba:899a:216:3eff:fecd:de74;3142;
=;enp7s0;IPv4;apt-cacher-ng\032proxy\032on\032test-bug1505670-focal;_apt_proxy._tcp;local;test-bug1505670-focal.local;10.232.244.137;3142;
=;enp6s0;IPv6;apt-cacher-ng\032proxy\032on\032test-bug1505670-focal;_apt_proxy._tcp;local;test-bug1505670-focal.local;fd42:bddd:a962:e084:216:3eff:fe11:a50c;3142;
=;enp6s0;IPv4;apt-cacher-ng\032proxy\032on\032test-bug1505670-focal;_apt_proxy._tcp;local;test-bug1505670-focal.local;10.115.171.242;3142;
=;enp5s0;IPv6;apt-cacher-ng\032proxy\032on\032test-bug1505670-focal;_apt_proxy._tcp;local;test-bug1505670-focal.local;fd42:ce31:bcba:21af:216:3eff:fe79:c522;3142;
=;enp5s0;IPv4;apt-cacher-ng\032proxy\032on\032test-bug1505670-focal;_apt_proxy._tcp;local;test-bug1505670-focal.local;10.47.127.209;3142;
=;lo;IPv4;apt-cacher-ng\032proxy\032on\032test-bug1505670-focal;_apt_proxy._tcp;local;test-bug1505670-focal.local;127.0.0.1;3142;
+;enp8s0;IPv6;apt-cacher-ng\032proxy\032on\032Camelot-TITAN;_apt_proxy._tcp;local
+;enp8s0;IPv4;apt-cacher-ng\032proxy\032on\032Camelot-TITAN;_apt_proxy._tcp;local
+;enp6s0;IPv6;apt-cacher-ng\032proxy\032on\032Camelot-TITAN;_apt_proxy._tcp;local
+;enp7s0;IPv6;apt-cacher-ng\032proxy\032on\032Camelot-TITAN;_apt_proxy._tcp;local
+;enp6s0;IPv4;apt-cacher-ng\032proxy\032on\032Camelot-TITAN;_apt_proxy._tcp;local
+;enp7s0;IPv4;apt-cacher-ng\032proxy\032on\032Camelot-TITAN;_apt_proxy._tcp;local
=;enp8s0;IPv6;apt-cacher-ng\032proxy\032on\032Camelot-TITAN;_apt_proxy._tcp;local;Camelot-TITAN.local;fd42:701b:b04:c7ab::1;3142;
=;enp8s0;IPv4;apt-cacher-ng\032proxy\032on\032Camelot-TITAN;_apt_proxy._tcp;local;Camelot-TITAN.local;10.8.60.1;3142;
=;enp6s0;IPv6;apt-cacher-ng\032proxy\032on\032Camelot-TITAN;_apt_proxy._tcp;local;Camelot-TITAN.local;fd42:bddd:a962:e084::1;3142;
=;enp7s0;IPv6;apt-cacher-ng\032proxy\032on\032Camelot-TITAN;_apt_proxy._tcp;local;Camelot-TITAN.local;fd42:3406:c5ba:899a::1;3142;
=;enp6s0;IPv4;apt-cacher-ng\032proxy\032on\032Camelot-TITAN;_apt_proxy._tcp;local;Camelot-TITAN.local;10.115.171.1;3142;
=;enp7s0;IPv4;apt-cacher-ng\032proxy\032on\032Camelot-TITAN;_apt_proxy._tcp;local;Camelot-TITAN.local;10.232.244.1;3142;

  # 5
  # After being announced stop the cacher on the host
  $ sudo systemctl stop apt-cacher-ng.service

  #6
  # Check it is now dead from the guests POV with curl <addr>:3142, i.e.:
  $ curl 10.8.60.155:3142
curl: (7) Failed to connect to 10.8.60.155 port 3142: Connection refused
  $ curl 10.232.244.137:3142
curl: (7) Failed to connect to 10.232.244.137 port 3142: Connection refused
  $ curl 10.115.171.242:3142
curl: (7) Failed to connect to 10.115.171.242 port 3142: Connection refused
$ curl 10.47.127.209:3142
curl: (7) Failed to connect to 10.47.127.209 port 3142: Connection refused

  #7
  # Ensure that it is still announced in avahi in the guest
  $ avahi-browse -kprtf _apt_proxy._tcp | grep '^=' | cut -d";" -f 4,8-9 | grep -v '::'
  ...
root@test-bug1505670-focal:~# avahi-browse -kprtf _apt_proxy._tcp | grep '^=' | cut -d";" -f 4,8-9 | grep -v '::'
[...]
apt-cacher-ng\032proxy\032on\032test-bug1505670-focal;fd42:701b:b04:c7ab:216:3eff:feda:f1e7;3142
apt-cacher-ng\032proxy\032on\032test-bug1505670-focal;fd42:3406:c5ba:899a:216:3eff:fecd:de74;3142
apt-cacher-ng\032proxy\032on\032test-bug1505670-focal;fd42:bddd:a962:e084:216:3eff:fe11:a50c;3142
apt-cacher-ng\032proxy\032on\032test-bug1505670-focal;fd42:ce31:bcba:21af:216:3eff:fe79:c522;3142
apt-cacher-ng\032proxy\032on\032test-bug1505670-focal;10.8.60.155;3142
apt-cacher-ng\032proxy\032on\032test-bug1505670-focal;10.232.244.137;3142
apt-cacher-ng\032proxy\032on\032test-bug1505670-focal;10.115.171.242;3142
apt-cacher-ng\032proxy\032on\032test-bug1505670-focal;10.47.127.209;3142
apt-cacher-ng\032proxy\032on\032test-bug1505670-focal;127.0.0.1;3142

### Bad response:

  #8
  # Now run apt-avahi-discover which shows the python errors
  # bleeding into the output even with stderr redirected
  $ /usr/share/squid-deb-proxy-client/apt-avahi-discover 2>/dev/null
  root@test-bug1505670-focal:~# /usr/share/squid-deb-proxy-client/apt-avahi-discover 2>/dev/null
error: uncaptured python exception, closing channel <AptAvahiClient> ('fd42:701b:b04:c7ab:216:3eff:feda:f1e7', 3142, 0, 0): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.8/asyncore.py|read|83] [/usr/lib/python3.8/asyncore.py|handle_read_event|417] [/usr/lib/python3.8/asyncore.py|handle_connect_event|425])
error: uncaptured python exception, closing channel <AptAvahiClient> ('fd42:3406:c5ba:899a:216:3eff:fecd:de74', 3142, 0, 0): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.8/asyncore.py|read|83] [/usr/lib/python3.8/asyncore.py|handle_read_event|417] [/usr/lib/python3.8/asyncore.py|handle_connect_event|425])
error: uncaptured python exception, closing channel <AptAvahiClient> ('fd42:bddd:a962:e084:216:3eff:fe11:a50c', 3142, 0, 0): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.8/asyncore.py|read|83] [/usr/lib/python3.8/asyncore.py|handle_read_event|417] [/usr/lib/python3.8/asyncore.py|handle_connect_event|425])
error: uncaptured python exception, closing channel <AptAvahiClient> ('fd42:ce31:bcba:21af:216:3eff:fe79:c522', 3142, 0, 0): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.8/asyncore.py|read|83] [/usr/lib/python3.8/asyncore.py|handle_read_event|417] [/usr/lib/python3.8/asyncore.py|handle_connect_event|425])
error: uncaptured python exception, closing channel <AptAvahiClient> ('10.8.60.155', 3142): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.8/asyncore.py|read|83] [/usr/lib/python3.8/asyncore.py|handle_read_event|417] [/usr/lib/python3.8/asyncore.py|handle_connect_event|425])
error: uncaptured python exception, closing channel <AptAvahiClient> ('10.232.244.137', 3142): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.8/asyncore.py|read|83] [/usr/lib/python3.8/asyncore.py|handle_read_event|417] [/usr/lib/python3.8/asyncore.py|handle_connect_event|425])
error: uncaptured python exception, closing channel <AptAvahiClient> ('10.115.171.242', 3142): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.8/asyncore.py|read|83] [/usr/lib/python3.8/asyncore.py|handle_read_event|417] [/usr/lib/python3.8/asyncore.py|handle_connect_event|425])
error: uncaptured python exception, closing channel <AptAvahiClient> ('10.47.127.209', 3142): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.8/asyncore.py|read|83] [/usr/lib/python3.8/asyncore.py|handle_read_event|417] [/usr/lib/python3.8/asyncore.py|handle_connect_event|425])
error: uncaptured python exception, closing channel <AptAvahiClient> ('127.0.0.1', 3142): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.8/asyncore.py|read|83] [/usr/lib/python3.8/asyncore.py|handle_read_event|417] [/usr/lib/python3.8/asyncore.py|handle_connect_event|425])
http://10.115.171.1:3142/

### Good response, after applying the fix from proposed package

# now no output bleeding through
$ /usr/share/squid-deb-proxy-client/apt-avahi-discover 2>/dev/null

# actually since there is no proxy left there is juts nothing now in this setup
$ /usr/share/squid-deb-proxy-client/apt-avahi-discover

  # But as soon as the cacher is back up it works:
  $ /usr/share/squid-deb-proxy-client/apt-avahi-discover
  http://10.115.171.1:3142/

[Where problems could occur]

As the change itself redirects the errors to the proper logs using the proper output flow (stderr), the risk of losing any kind of information is avoided as well as the risk to produce any kind of interference with the rest of the system. It uses standard python calls to do it, so it doesn't have to rely on anything in particular.

[Other Info]

The change is cherry-picked from upstream for fixing this bug precisely: https://github.com/mvo5/squid-deb-proxy/commit/604ba3f98beff25a8fd51783d3ffc4db5e987dab (Thanks to @mvo)

[Original Report]
-------------------------------------------------------------------
Steps to reproduce (for later SRU work)

#0
# On the test Host install apt-cacher-ng
# you need to do so before creating the guest to propagate
# and configure correctly when spawned
$ sudo apt install apt-cacher-ng

#1
# create a VM guest or container with at least three IPv4 adresses
# In the example below I used 4 virtio net in KVM all with DHCP configured

#2
# install prereq packages
$ sudo apt install avahi-utils squid-deb-proxy-client

#3
# check if all are interfaces are configured and avahi probes them all
# (you might need to edit netplan or E/N/I to e.g. dhcp on all of them)
$ avahi-browse -kprtf _apt_proxy._tcp
+;enp9s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+;enp9s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
+;enp9s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+;enp8s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+;enp8s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
+;enp8s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+;enp7s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+;enp7s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
+;enp7s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+;enp1s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+;enp1s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
+;enp1s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+;lo;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
=;enp8s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local;Keschdeichel.local;192.168.122.1;3142;
=;enp9s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local;Keschdeichel.local;192.168.122.1;3142;
=;enp7s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local;Keschdeichel.local;192.168.122.1;3142;
=;enp1s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local;Keschdeichel.local;192.168.122.1;3142;
=;enp9s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;fe80::5054:ff:fe3a:53e7;8000;
=;enp8s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;fe80::5054:ff:fe73:b27d;8000;
=;enp7s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;fe80::5054:ff:fe3a:53e7;8000;
=;enp1s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;fe80::5054:ff:fe4e:2923;8000;
=;enp9s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;192.168.122.125;8000;
=;enp8s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;192.168.122.202;8000;
=;enp7s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;192.168.122.186;8000;
=;enp1s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;192.168.122.42;8000;
=;lo;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;127.0.0.1;8000;

#5
# After being announced stop the cacher on the host
$ sudo systemctl stop apt-cacher-ng.service

#6
Check it is now dead from the guests POV
$ curl 192.168.122.1:3142
curl: (7) Failed to connect to 192.168.122.1 port 3142: Connection refused

#7
# Ensure that it is still announced in avahi in the guest
$ avahi-browse -kprtf _apt_proxy._tcp | grep '^=' | cut -d";" -f 4,8-9 | grep -v '::'
...
apt-cacher-ng\032proxy\032on\032Keschdeichel;192.168.122.1;3142

#8
# Now run apt-avahi-discover which shows the python errors
# bleeding into the output even with stderr redirected
$ /usr/share/squid-deb-proxy-client/apt-avahi-discover 2>/dev/null
error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.122.1', 3142): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.9/asyncore.py|read|83] [/usr/lib/python3.9/asyncore.py|handle_read_event|417] [/usr/lib/python3.9/asyncore.py|handle_connect_event|425])
error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.122.1', 3142): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.9/asyncore.py|read|83] [/usr/lib/python3.9/asyncore.py|handle_read_event|417] [/usr/lib/python3.9/asyncore.py|handle_connect_event|425])
error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.122.1', 3142): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.9/asyncore.py|read|83] [/usr/lib/python3.9/asyncore.py|handle_read_event|417] [/usr/lib/python3.9/asyncore.py|handle_connect_event|425])
error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.122.1', 3142): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.9/asyncore.py|read|83] [/usr/lib/python3.9/asyncore.py|handle_read_event|417] [/usr/lib/python3.9/asyncore.py|handle_connect_event|425])
http://192.168.122.42:8000/

P.S. I'm (paelzer) not entirely sure we need "multiple" IPs an announced but down entry might be enough, but we want to stick close to what was reported.

---

I get the following error when running the discovery script on the command line.

$ /usr/share/squid-deb-proxy-client/apt-avahi-discover
error: uncaptured python exception, closing channel <AptAvahiClient> ('10.1.2.3', 3142): 2147483647 (<class 'socket.error'>:[Errno 111] Connection refused [/usr/lib/python2.7/asyncore.py|read|83] [/usr/lib/python2.7/asyncore.py|handle_read_event|446] [/usr/lib/python2.7/asyncore.py|handle_connect_event|454])
error: uncaptured python exception, closing channel <AptAvahiClient> ('10.0.3.1', 3142): 2147483647 (<class 'socket.error'>:[Errno 111] Connection refused [/usr/lib/python2.7/asyncore.py|read|83] [/usr/lib/python2.7/asyncore.py|handle_read_event|446] [/usr/lib/python2.7/asyncore.py|handle_connect_event|454])
error: uncaptured python exception, closing channel <AptAvahiClient> ('172.24.74.129', 3142): 2147483647 (<class 'socket.error'>:[Errno 111] Connection refused [/usr/lib/python2.7/asyncore.py|read|83] [/usr/lib/python2.7/asyncore.py|handle_read_event|446] [/usr/lib/python2.7/asyncore.py|handle_connect_event|454])
http://172.24.74.145:3142/

The last line still returns the proper proxy URI so as far as I can tell things are still working. The IP 10.1.2.3 is for an n2n VPN. This is on trusty with version 0.8.6ubuntu1.

To trigger the bug the environment setup needs to be in a specific way.
It seems for the problem to occur it need more than one host/IP discovered via avahi. This can be probed via $ avahi-browse -kprtf _apt_proxy._tcp
and e.g. the common LXD setup of IPv4 + ipv6 is NOT enough to trigger it.

TODO: a sample output of the above command in an affected environment could be helpful.

TODO: if possible outlining how the environment can be configured to have this multi host/IP reply in avahi would be helpful as well.

See original description

Tags:

Related branches

~mirespace/ubuntu/+source/squid-deb-proxy:sru-bionic-squid-deb-proxy-lp1505670-apt-avahi-discover

Merged into ubuntu/+source/squid-deb-proxy:ubuntu/bionic-devel at revision f67413f3255fbfa43f57bd53c2c60d816e14d83e

Sergio Durigan Junior (community): Approve on 2021-10-26

Canonical Server MOTU reviewers: Pending requested 2021-10-15

~mirespace/ubuntu/+source/squid-deb-proxy:sru-focal-squid-deb-proxy-lp1505670-apt-avahi-discover

Merged into ubuntu/+source/squid-deb-proxy:ubuntu/focal-devel at revision 7f0da64a695af9f14c15b87928bb10100b897801

Sergio Durigan Junior (community): Approve on 2021-10-26

Canonical Server MOTU reviewers: Pending requested 2021-10-15

~mirespace/ubuntu/+source/squid-deb-proxy:sru-hirsute-squid-deb-proxy-lp1505670-apt-avahi-discover

Merged into ubuntu/+source/squid-deb-proxy:ubuntu/hirsute-devel at revision e278643bdfd325844f56e23743e15cc8194e79f6

Sergio Durigan Junior (community): Approve on 2021-10-26

Canonical Server MOTU reviewers: Pending requested 2021-10-15

~mirespace/ubuntu/+source/squid-deb-proxy:impish-squid-deb-proxy-lp1505670-apt-avahi-discover

Merged into ubuntu/+source/squid-deb-proxy:ubuntu/devel at revision e0129da38e8b2c3c74e9b4d7b83861f14c91a38c

Christian Ehrhardt  (community): Approve on 2021-10-06

Utkarsh Gupta (community): Needs Fixing on 2021-10-05

Revision history for this message

cell (jasonpepas) wrote on 2015-10-18:

Download full text (3.6 KiB)

I just ran into this bug, and I think I've figured it out.

/usr/share/squid-deb-proxy-client/apt-avahi-discover is outputting the URL of my squid-deb-proxy server, but it is also spitting out some errors:

root@debian:~# /usr/share/squid-deb-proxy-client/apt-avahi-discover
error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.2.232', 3142): 9223372036854775807 (<class 'socket.error'>:[Errno 111] Connection refused [/usr/lib/python2.7/asyncore.py|read|83] [/usr/lib/python2.7/asyncore.py|handle_read_event|446] [/usr/lib/python2.7/asyncore.py|handle_connect_event|454])
error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.2.80', 3142): 9223372036854775807 (<class 'socket.error'>:[Errno 111] Connection refused [/usr/lib/python2.7/asyncore.py|read|83] [/usr/lib/python2.7/asyncore.py|handle_read_event|446] [/usr/lib/python2.7/asyncore.py|handle_connect_event|454])
http://192.168.2.232:8000/]

The problem here is that the errors are going to stdout, not to stderr. This means apt's Acquire::http::ProxyAutoDetect is not able to figure out what the proxy URL is.

I have locally modified apt-avahi-discover so that the errors are sent to stderr, and I have verified that this allows apt's Acquire::http::ProxyAutoDetect to work correctly. I have attached this as a patch.

This patch is enough to fix this bug, but I'm not sure it's ultimately the best fix for the overall issue. I think ideally, in the case were apt-avahi-discover encounters non-fatal errors (and is still able to produce a working URL), these error should probably just get logged to syslog, rather than being sent to stderr, because it does make apt's console output look rather ugly, and the user doesn't need to see any of that, because if there's a working URL, ultimately they don't care any other errors.

(This is what apt's output looks like with the patch applied to apt-avahi-discover:)

0 upgraded, 826 newly installed, 0 to remove and 1 not upgraded.
Need to get 500 MB of archives.
After this operation, 1,554 MB of additional disk space will be used.
Do you want to continue? [Y/n]
0% [Working]log: error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.2.80', 3142): 9223372036854775807 (<class 'socket.error'>:[Errno 111] Connection refused [/usr/lib/python2.7/asyncore.py|read|83] [/usr/lib/python2.7/asyncore.py|handle_read_event|446] [/usr/lib/python2.7/asyncore.py|handle_connect_event|454])
log: error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.2.232', 3142): 9223372036854775807 (<class 'socket.error'>:[Errno 111] Connection refused [/usr/lib/python2.7/asyncore.py|read|83] [/usr/lib/python2.7/asyncore.py|handle_read_event|446] [/usr/lib/python2.7/asyncore.py|handle_connect_event|454])
log: error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.2.80', 3142): 9223372036854775807 (<class 'socket.error'>:[Errno 111] Connection refused [/usr/lib/python2.7/asyncore.py|read|83] [/usr/lib/python2.7/asyncore.py|handle_read_event|446] [/usr/lib/python2.7/asyncore.py|handle_connect_event|454])
log: error: uncaptured python exception, closing channel <AptAvahiClient> (...

I just ran into this bug, and I think I've figured it out.

/usr/share/squid-deb-proxy-client/apt-avahi-discover is outputting the URL of my squid-deb-proxy server, but it is also spitting out some errors:

root@debian:~# /usr/share/squid-deb-proxy-client/apt-avahi-discover 
error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.2.232', 3142): 9223372036854775807 (<class 'socket.error'>:[Errno 111] Connection refused [/usr/lib/python2.7/asyncore.py|read|83] [/usr/lib/python2.7/asyncore.py|handle_read_event|446] [/usr/lib/python2.7/asyncore.py|handle_connect_event|454])
error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.2.80', 3142): 9223372036854775807 (<class 'socket.error'>:[Errno 111] Connection refused [/usr/lib/python2.7/asyncore.py|read|83] [/usr/lib/python2.7/asyncore.py|handle_read_event|446] [/usr/lib/python2.7/asyncore.py|handle_connect_event|454])
http://192.168.2.232:8000/]

The problem here is that the errors are going to stdout, not to stderr.  This means apt's Acquire::http::ProxyAutoDetect is not able to figure out what the proxy URL is.

This patch is enough to fix this bug, but I'm not sure it's ultimately the best fix for the overall issue.  I think ideally, in the case were apt-avahi-discover encounters non-fatal errors (and is still able to produce a working URL), these error should probably just get logged to syslog, rather than being sent to stderr, because it does make apt's console output look rather ugly, and the user doesn't need to see any of that, because if there's a working URL, ultimately they don't care any other errors.

(This is what apt's output looks like with the patch applied to apt-avahi-discover:)

0 upgraded, 826 newly installed, 0 to remove and 1 not upgraded.
Need to get 500 MB of archives.
After this operation, 1,554 MB of additional disk space will be used.
Do you want to continue? [Y/n] 
0% [Working]log: error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.2.80', 3142): 9223372036854775807 (<class 'socket.error'>:[Errno 111] Connection refused [/usr/lib/python2.7/asyncore.py|read|83] [/usr/lib/python2.7/asyncore.py|handle_read_event|446] [/usr/lib/python2.7/asyncore.py|handle_connect_event|454])
log: error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.2.232', 3142): 9223372036854775807 (<class 'socket.error'>:[Errno 111] Connection refused [/usr/lib/python2.7/asyncore.py|read|83] [/usr/lib/python2.7/asyncore.py|handle_read_event|446] [/usr/lib/python2.7/asyncore.py|handle_connect_event|454])
log: error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.2.80', 3142): 9223372036854775807 (<class 'socket.error'>:[Errno 111] Connection refused [/usr/lib/python2.7/asyncore.py|read|83] [/usr/lib/python2.7/asyncore.py|handle_read_event|446] [/usr/lib/python2.7/asyncore.py|handle_connect_event|454])
log: error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.2.232', 3142): 9223372036854775807 (<class 'socket.error'>:[Errno 111] Connection refused [/usr/lib/python2.7/asyncore.py|read|83] [/usr/lib/python2.7/asyncore.py|handle_read_event|446] [/usr/lib/python2.7/asyncore.py|handle_connect_event|454])
Get:1 http://ftp.us.debian.org/debian/ jessie/main alsa-base all 1.0.27+1 [54.3 kB]
Get:2 http://ftp.us.debian.org/debian/ jessie/main libcroco3 amd64 0.6.8-3+b1 [135 kB]
Get:3 http://security.debian.org/ jessie/updates/main libvdpau1 amd64 0.8-3+deb8u1 [33.5 kB]

Revision history for this message

Ubuntu Foundations Team Bug Bot (crichton) wrote on 2015-10-18:

The attachment "Minimal patch to work-around this bug." seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags:

added: patch

Revision history for this message

cell (jasonpepas) wrote on 2015-10-18:

Minimal patch to work-around this bug. Edit (554 bytes, text/plain)

(oops, the previous patch had some garbage at the top. re-attaching the patch here).

Revision history for this message

cell (jasonpepas) wrote on 2015-10-18:

Revised, syslog-based solution. Edit (697 bytes, text/plain)

So, I went ahead and made a different version of the patch which sends asyncore's logging output to syslog, instead of stderr. This keep's apt-get's output clean.

I think this is the patch I'd prefer. However, I should probably also bark up the tree of asyncore.py and ask why they are calling 'print' on something labelled as an 'error' instead of just throwing an exception (which would allow apt-avahi-discover to deal with it appropriately).

(see attached patch).

Revision history for this message

Rolf Leggewie (r0lf) wrote on 2015-10-19:

Thanks, Jason! I applied the patch locally and indeed it works beautifully.

I hope it lands soon and gets backported to trusty.

Revision history for this message

Rolf Leggewie (r0lf) wrote on 2015-10-19:

@mvo, it would be nice if you took the time to consider inclusion of the patch from comment 4

Changed in squid-deb-proxy (Ubuntu):
status:	New → In Progress

Revision history for this message

Rolf Leggewie (r0lf) wrote on 2017-03-04:

Going by what's written here and in bug 1422162 it looks like this problem occurs whenever there is more than one host/IP discovered via avahi.

Rolf Leggewie (r0lf) on 2019-05-04

Changed in squid-deb-proxy (Ubuntu):
status:	In Progress → Confirmed

Revision history for this message

Andreas Hasenack (ahasenack) wrote on 2019-05-06:

I believe this is fixed in eoan at least:

root@eoan-squid-deb-proxy-clienbt:~# rm -f errors.txt
root@eoan-squid-deb-proxy-clienbt:~# /usr/share/squid-deb-proxy-client/apt-avahi-discover 2>errors.txt
http://10.0.100.99:8000/
root@eoan-squid-deb-proxy-clienbt:~# cat errors.txt
Failed to resolve service 'Squid deb proxy on eoan-squid-deb-proxy2' of type '_apt_proxy._tcp' in domain 'local': Timeout reached
root@eoan-squid-deb-proxy-clienbt:~#

apt update works just fine, but it spits out the error, as mentioned in comment #3:
root@eoan-squid-deb-proxy-clienbt:~# apt update
Failed to resolve service 'Squid deb proxy on eoan-squid-deb-proxy2' of type '_apt_proxy._tcp' in domain 'local': Timeout reached
Hit:1 http://archive.ubuntu.com/ubuntu eoan InRelease
Hit:2 http://archive.ubuntu.com/ubuntu eoan-updates InRelease
Hit:3 http://archive.ubuntu.com/ubuntu eoan-backports InRelease
Hit:4 http://archive.ubuntu.com/ubuntu eoan-security InRelease
Reading package lists... Done
Building dependency tree
Reading state information... Done
4 packages can be upgraded. Run 'apt list --upgradable' to see them.

Same in xenial, so I'll assume the versions in between are also ok:root@xenial-squid-deb-proxy-client:~# /usr/share/squid-deb-proxy-client/apt-avahi-discover
Failed to resolve service 'Squid deb proxy on eoan-squid-deb-proxy2' of type '_apt_proxy._tcp' in domain 'local': Timeout reached
http://10.0.100.99:8000/
root@xenial-squid-deb-proxy-client:~# /usr/share/squid-deb-proxy-client/apt-avahi-discover 2>/dev/null
http://10.0.100.99:8000/
root@xenial-squid-deb-proxy-client:~#

root@xenial-squid-deb-proxy-client:~# apt update
0% [Working]Failed to resolve service 'Squid deb proxy on eoan-squid-deb-proxy2' of type '_apt_proxy._tcp' in domain 'local': Timeout reached
Failed to resolve service 'Squid deb proxy on eoan-squid-deb-proxy2' of type '_apt_proxy._tcp' in domain 'local': Timeout reached
Hit:1 http://archive.canonical.com/ubuntu xenial InRelease
Hit:2 http://br.archive.ubuntu.com/ubuntu xenial InRelease
Hit:3 http://br.archive.ubuntu.com/ubuntu xenial-updates InRelease
Hit:4 http://br.archive.ubuntu.com/ubuntu xenial-backports InRelease
Hit:5 http://br.archive.ubuntu.com/ubuntu xenial-security InRelease
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
root@xenial-squid-deb-proxy-client:~# echo $?
0
root@xenial-squid-deb-proxy-client:~#

I believe this is fixed in eoan at least:

root@eoan-squid-deb-proxy-clienbt:~# rm -f errors.txt
root@eoan-squid-deb-proxy-clienbt:~# /usr/share/squid-deb-proxy-client/apt-avahi-discover 2>errors.txt
http://10.0.100.99:8000/
root@eoan-squid-deb-proxy-clienbt:~# cat errors.txt 
Failed to resolve service 'Squid deb proxy on eoan-squid-deb-proxy2' of type '_apt_proxy._tcp' in domain 'local': Timeout reached
root@eoan-squid-deb-proxy-clienbt:~#

apt update works just fine, but it spits out the error, as mentioned in comment #3:
root@eoan-squid-deb-proxy-clienbt:~# apt update
Failed to resolve service 'Squid deb proxy on eoan-squid-deb-proxy2' of type '_apt_proxy._tcp' in domain 'local': Timeout reached
Hit:1 http://archive.ubuntu.com/ubuntu eoan InRelease
Hit:2 http://archive.ubuntu.com/ubuntu eoan-updates InRelease
Hit:3 http://archive.ubuntu.com/ubuntu eoan-backports InRelease
Hit:4 http://archive.ubuntu.com/ubuntu eoan-security InRelease
Reading package lists... Done
Building dependency tree       
Reading state information... Done
4 packages can be upgraded. Run 'apt list --upgradable' to see them.

root@xenial-squid-deb-proxy-client:~# apt update
0% [Working]Failed to resolve service 'Squid deb proxy on eoan-squid-deb-proxy2' of type '_apt_proxy._tcp' in domain 'local': Timeout reached
Failed to resolve service 'Squid deb proxy on eoan-squid-deb-proxy2' of type '_apt_proxy._tcp' in domain 'local': Timeout reached
Hit:1 http://archive.canonical.com/ubuntu xenial InRelease
Hit:2 http://br.archive.ubuntu.com/ubuntu xenial InRelease
Hit:3 http://br.archive.ubuntu.com/ubuntu xenial-updates InRelease
Hit:4 http://br.archive.ubuntu.com/ubuntu xenial-backports InRelease
Hit:5 http://br.archive.ubuntu.com/ubuntu xenial-security InRelease
Reading package lists... Done
Building dependency tree       
Reading state information... Done
All packages are up to date.
root@xenial-squid-deb-proxy-client:~# echo $?
0
root@xenial-squid-deb-proxy-client:~#

Changed in squid-deb-proxy (Ubuntu):
status:	Confirmed → Fix Released

Revision history for this message

Rolf Leggewie (r0lf) wrote on 2020-04-24:

Andreas, I cannot confirm this for focal and I believe you should have asked for confirmation from others before closing.

Code inspection suggests nothing was done to fix this bug, but of course it was possible that a change in asyncore.py fixed this. That does not look to be the case. I tested the patch from #4 again, it works and I believe it should be applied in focal and bionic.

$ /usr/share/squid-deb-proxy-client/apt-avahi-discover
error: uncaptured python exception, closing channel <AptAvahiClient> ('2003:d3:b725:fb45:290:27ff:fe25:f52', 3142, 0, 0): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.8/asyncore.py|read|83] [/usr/lib/python3.8/asyncore.py|handle_read_event|417] [/usr/lib/python3.8/asyncore.py|handle_connect_event|425])
error: uncaptured python exception, closing channel <AptAvahiClient> ('2003:d3:b725:fb45:290:27ff:fe25:f52', 3142, 0, 0): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.8/asyncore.py|read|83] [/usr/lib/python3.8/asyncore.py|handle_read_event|417] [/usr/lib/python3.8/asyncore.py|handle_connect_event|425])
error: uncaptured python exception, closing channel <AptAvahiClient> ('2003:d3:b725:fb45:2e0:c5ff:fe34:f66c', 3142, 0, 0): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.8/asyncore.py|read|83] [/usr/lib/python3.8/asyncore.py|handle_read_event|417] [/usr/lib/python3.8/asyncore.py|handle_connect_event|425])
error: uncaptured python exception, closing channel <AptAvahiClient> ('2003:d3:b725:fb45:2e0:c5ff:fe34:f66c', 3142, 0, 0): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.8/asyncore.py|read|83] [/usr/lib/python3.8/asyncore.py|handle_read_event|417] [/usr/lib/python3.8/asyncore.py|handle_connect_event|425])
error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.34.22', 3142): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.8/asyncore.py|read|83] [/usr/lib/python3.8/asyncore.py|handle_read_event|417] [/usr/lib/python3.8/asyncore.py|handle_connect_event|425])
error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.34.22', 3142): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.8/asyncore.py|read|83] [/usr/lib/python3.8/asyncore.py|handle_read_event|417] [/usr/lib/python3.8/asyncore.py|handle_connect_event|425])
http://192.168.34.5:3142/

Andreas, I cannot confirm this for focal and I believe you should have asked for confirmation from others before closing.

Code inspection suggests nothing was done to fix this bug, but of course it was possible that a change in asyncore.py fixed this.  That does not look to be the case.  I tested the patch from #4 again, it works and I believe it should be applied in focal and bionic.

Changed in squid-deb-proxy (Ubuntu):
status:	Fix Released → Confirmed

Rolf Leggewie (r0lf) on 2020-04-24

tags:	added: bionic
tags:	added: focal

Revision history for this message

Rolf Leggewie (r0lf) wrote on 2020-05-02:

#10

filing against python2.7 as well based on comment #4

Revision history for this message

Rolf Leggewie (r0lf) wrote on 2021-02-17:

#11

I've long been using the patch from this ticket successfully and have now published a bionic package in my LTS ppa https://launchpad.net/~r0lf/+archive/ubuntu/stable Other release pockets to follow.

Revision history for this message

Lucas Kanashiro (lucaskanashiro) wrote on 2021-08-17:

#12

@Rolf and others, thanks for all the testing done so far. Since the importance is set to Low I do not believe we will have time to tackle this anytime soon, but I'd be happy to sponsor a fixed package if anyone wants to work on it. In order to land this fix we would need to follow the SRU process:

https://wiki.ubuntu.com/StableReleaseUpdates

Once we have the SRU bug description in place and a debdiff, we can review the and sponsor your work.

Revision history for this message

Rolf Leggewie (r0lf) wrote on 2021-08-20:

#13

Thanks, Lucas.

As far as I'm aware, this was never addressed upstream and thus still affects ubuntu+1 (ping @mvo). So, before SRU this needs to be fixed in ubuntu+1. The patch from #4 is what I've been using for the last few years without a hitch. It would certainly be nice for it to land before a decade is up.

Revision history for this message

Miriam España Acebal (mirespace) wrote on 2021-08-31:

#14

Hi Rolf,

I'm trying to reproduce the issue on impish, but I only get this:

root@ondevelopment:~# /usr/share/squid-deb-proxy-client/apt-avahi-discover
error: uncaptured python exception, closing channel <AptAvahiClient> ('fd42:ce31:bcba:21af:216:3eff:fe27:28d6', 8000, 0, 0): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.9/asyncore.py|read|83] [/usr/lib/python3.9/asyncore.py|handle_read_event|417] [/usr/lib/python3.9/asyncore.py|handle_connect_event|425])

when removing squid-deb-proxy. Otherwise, I get this:

root@ondevelopment:~# /usr/share/squid-deb-proxy-client/apt-avahi-discover
http://127.0.0.1:8000/
root@ondevelopment:~# /usr/share/squid-deb-proxy-client/apt-avahi-discover
http://[fd42:ce31:bcba:21af:216:3eff:fe27:28d6]:8000/

Could you be so kind to share steps to reproduce or some configuration needed? I would appreciate it... thanks.

Revision history for this message

Rolf Leggewie (r0lf) wrote on 2021-09-27:

#15

Thank, Miriam, for having a look. I only became aware of your response now by accident.

I'm not sure I understand what you did and what your results were. It appears that you got the issue of an "uncaptured python exception" at least once "when you removed squid-deb-proxy"? I really don't know what you mean there. Then you list the output of /usr/share/squid-deb-proxy-client/apt-avahi-discover twice, unchanged, but apparently get an IPv4 result once and an IPv6 result on the next, identical invocation.

The problem with squid-deb-proxy is easy to trigger. All it needs is two or more responses to the avahi discovery in your LAN. See the initial report where it shows three different IP numbers. These days, I believe an IPv4 and IPv6 response from the same server is actually enough.

Frankly, we don't need more bug triage here, it's all been laid out forever, we've had a working patch for years. The patch is as far as I can tell correct in that it is not simply a workaround. I assume you haven't looked at the code. What needs to be done here is for @mvo to finally comment on whether or not this is the correct way to fix it or reject the patch (and come up with an alternative patch).

Truth be told, the state of this bug is disgusting and demotivating. Ubuntu used to be about making Debian polished and usable. How come we dropped the ball so badly on this awesome USP?

Revision history for this message

Rolf Leggewie (r0lf) wrote on 2021-09-27:

#16

@Miriam, actually, all that I've written has been mentioned before in the bug ticket. Have you actually read the ticket? Why is it that people who get paid by Canonical to work on Ubuntu can't even be bothered to read the tickets where volunteers who don't get paid have already done their work (you are not the first and not the second employee where I noticed this)?

Christian Ehrhardt  (paelzer) on 2021-09-30

description:

updated

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2021-09-30:

#17

Download full text (7.8 KiB)

Hi Rolf,
let me try to calm things down a bit via clarifications on the
technical and ubuntu-process side of this.

> I'm not sure I understand what you did and what your results were. It
> appears that you got the issue of an "uncaptured python exception" at
> least once "when you removed squid-deb-proxy"? I really don't know what
> you mean there. Then you list the output of /usr/share/squid-deb-proxy-
> client/apt-avahi-discover twice, unchanged, but apparently get an IPv4
> result once and an IPv6 result on the next, identical invocation.

The bug initially just describes to run apt-avahi-discover and it would fail.
That is exactly what everyone retrying it here did AFAICS.
But that does not fail that way.

The later insight posted on the bug that "more than one host/IP discovered via avahi" are required isn't enough either. The setup those people used has Ipv4+ipv6 = 2 IPs in avahi but still work fine.

And yes - as you quoted on Miriams example - under that condition it is reporting one of the potential IPv4/IPv6 proxy addresses in a random fashion and that might be another bug. But not a problem here.

It seems @Miriam then still didn't give up on your case, but went further trying to provoke a similar exception by removing some of the python sources and wondered if that could be similar to the reported issue. It isn't similar nor helpful in hindsight - but I appreciate that she did insist on trying to help you by evaluating other options.

> The problem with squid-deb-proxy is easy to trigger. All it needs is two
> or more responses to the avahi discovery in your LAN. See the initial
> report where it shows three different IP numbers. These days, I believe an
> IPv4 and IPv6 response from the same server is actually enough.

I've re-read it all again, but the bug description (= the initial report) does not tell that in any way. "Three" as in your last post definitely isn't mentioned anywhere before and as I outlined before "multiple" was mentioned but IPv4+IPv6 = 2 and that does not trigger it.

Comment #1 then re-analyzed the same issue providing an initial fix which is great, but still has no further details how to reproduce this. Up to comment #4 it is about revising the patch, you then kindly tested the patch #5 and called for consideration #6.
So far all was great, and then I agree the lack of a reaction then is what makes this a bad case.

Then in comment #7 you clarified that to trigger it one will need "more than one host/IP discovered via avahi." But the test setup that Andreas (comment #8) and Miriam (comment #14) was a common LXD setup which has multiple IPs which also causes the alternating ipv4/ipv6 responses.

For example here from a similar setup to the one they used:

$ avahi-browse -kprtf _apt_proxy._tcp
+;eth0;IPv6;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
+;eth0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
=;eth0;IPv6;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local;Keschdeichel.local;fd42:fa18:c923:35d5::1;3142;
=;eth0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local;Keschdeichel.local;10.253.194.1;3142;

So it might s...

Hi Rolf,
let me try to calm things down a bit via clarifications on the
technical and ubuntu-process side of this.

The bug initially just describes to run apt-avahi-discover and it would fail.
That is exactly what everyone retrying it here did AFAICS.
But that does not fail that way.

The later insight posted on the bug that "more than one host/IP discovered via avahi" are required isn't enough either. The setup those people used has Ipv4+ipv6 = 2 IPs in avahi but still work fine.

I've re-read it all again, but the bug description (= the initial report) does not tell that in any way.  "Three" as in your last post definitely isn't mentioned anywhere before and as I outlined before "multiple" was mentioned but IPv4+IPv6 = 2 and that does not trigger it.

For example here from a similar setup to the one they used:

So it might strictly need multiple-hosts with multiple-ipv4 adresses then?
Or is it three (as you say above)?
Or "three or more?"
If so is it "three or more IPv4?" or does IPv47IPv6 not matter?
Can those IPs be on the same host, or does it have to be different systems?
...
You do know at least from your example, but we or anyone else just reading the case does not.

And as far as I read comment #14 Miriam is mostly asking for "I don't see your issue here can you help me to see why". The proper answer would IMHO be elaborating out how to setup the surrounding environment so that avahi-browse will return a set of hosts/IPs that will make it break avahi.

BTW no one ever adapted the bug description summarizing any of the new insights - I did this now to help anyone looking at it later on. There are a few open questions there which you might be able to fill in @Rolf.

> Frankly, we don't need more bug triage here, it's all been laid out
> forever, we've had a working patch for years. The patch is as far as I can
> tell correct in that it is not simply a workaround. I assume you haven't
> looked at the code.

That might be another misunderstanding - again let me try to help to clarify.
This isn't so much about triaging, but about finding a way to reliable steps to recreate it.
They want to help you and anyone else affected, but to apply the patch to anything else but future Ubuntu releases it will have to go through the SRU process [1] and that rather strictly dictates reproducibility for a test along the publishing & verification. So without very special conditions the lack of a clear test/repro can be almost as inhibiting as the lack of a fix in
the first place.

> Truth be told, the state of this bug is disgusting and demotivating.
> Ubuntu used to be about making Debian polished and usable. How come we
> dropped the ball so badly on this awesome USP?

This section is more assumption/opinion than knowledge, to be clear I agree it is dormant way too long.

But there are also reasons this might have happened. Squid-deb-proxy is not in main [2] and thereby might get less polishing and attention than you are used from other portions that make up Ubuntu. Handling of Universe packages depends mostly on the activity of the maintainer and/or a community around its users. Looking back at all the years "Ubuntu" as in [2] "Main - Canonical-
supported free and open-source software." has certainly got much better.
Response times, patch quality, regular updates and maintenance, extended use cases, even bug handling - which is the problem here - got way better. But there are things in Universe that do not get that much attention.

> ... Have you actually read the ticket? ...

Actually I think people have really read it, but as I outlined above it just
isn't as clear to someone else looking at the case than it is to you.

You have to understand that people that want to help might still never consciously have used squid-deb-proxy-client and/or avahi before. But they still want to help by preparing the steps needed to get the fix finally landed into Ubuntu.

And in reverse it doesn't seem helpful to drive those people away that try to help - even out of rightful frustration for a lack of a timely reaction.

An alternative read of the "have you actually read the ticket" situation reoccuring could be "if multiple people don't get it, maybe the content/explanations aren't as clear as I thought".
I hope my updates here and to the description will help to avoid that aspect from ever being a problem again on this case.

>  What needs to be done here is for @mvo to finally
> comment on whether or not this is the correct way to fix it or reject the
> patch (and come up with an alternative patch).

Again - I understand your frustration since this clearly is too much time, but as you say we will need to get MVO to have a look since he is the upstream&debian maintainer of the package.
I'd assume his many other duties these days just made him not see the case yet.

I want to help to get this resolved, but IMHO the lack of that response isn't justifying the hard language to Miriam or Ubuntu Developers in general. It is not my mission nor intent to further resolve the social aspect of this, but I wanted to state that to not leave all of them out in the rain alone.

So, no matter how late it is, I agree that (other than missing valid steps to recreate for the SRU policies as I mentioned above) one thing we need is MVO to consider,ack and apply it in the upstream repo.

I have contacted him via the IRC info that is on every developers [3] page and he said he will later today have a look at it.

Kind regards,
Christian

[1]: https://wiki.ubuntu.com/StableReleaseUpdates
[2]: https://help.ubuntu.com/community/Repositories/Ubuntu
[3]: https://launchpad.net/~mvo

Revision history for this message

Michael Vogt (mvo) wrote on 2021-09-30:

#18

My apologizes that this totally was not on my radar. I applied the patch (thank you!) and moved the code from bzr to git, added a gbp.conf and pushed to GH for now (but maybe this really should go to salsa instead). I hope I will be able to release a new .16 release with these changes (and the most recent Debian NMU changes). Sorry again.

Revision history for this message

Rolf Leggewie (r0lf) wrote on 2021-09-30:

#19

Christian, thank you for stepping in. It seems you finally got the ball rolling here where I was unsuccessful in a good half dozen attempts in #ubuntu-devel and other venues. That's the good news I suppose.

I maintain my assessment of the situation of Ubuntu as stated in #16. I've been with Ubuntu since breezy or so. I've been very active in bug triage, I know the processes. I'm happy to back up my rant with facts, if you want to hear.

I also maintain that this bug ticket and the problem was clearly described including a test case in #7 and a clear analysis of where the problem is IN THE CODE right in #1. You don't need more bug triage at that point. You need a dev to look at the code and that did not happen, no matter the effort, here and elsewhere. I believe I even tried to get the patch sponsored but nobody dared touching mvo's stuff without an ACK.

I'm not sure, but it seems that both you and Miriam mistakenly assume that this bug can be triggered by some configuration on the computer where squid-deb-proxy-CLIENT is installed. As stated in #7 "this problem occurs whenever there is more than one host/IP discovered via avahi." in other words, a certain state of affairs with regards to the LAN (plus VPNs) is needed.

Christian Ehrhardt  (paelzer) on 2021-10-05

description:

updated

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2021-10-05:

#20

Download full text (12.3 KiB)

> Christian, thank you for stepping in. It seems you finally got the ball rolling
> here where I was unsuccessful in a good half dozen attempts in #ubuntu-devel
> and other venues. That's the good news I suppose.

Np, glad to help - although this time as you said it was more "stepping in" as I wanted to avoid things getting out of control between several people that all only want to help to improve Ubuntu.

> I maintain my assessment of the situation of Ubuntu as stated in #16. I've been
> with Ubuntu since breezy or so. I've been very active in bug triage, I know the
> processes. I'm happy to back up my rant with facts, if you want to hear.

TBH - You don't really have to provide other evidence, I've seen you triage and comment on many cases as I'm active myself. And I'm glad about your and other community members work!
Also I know that sometimes cases can be forgotten, ignored or punted too long for various reasons that are too manifold to be covered here.
My personal and my teams stance is to help to resolve those cases we come by and to help training (our and other) people if we see a structural issue.

> I also maintain that this bug ticket and the problem was clearly described including a
> test case in #7 and a clear analysis of where the problem is IN THE CODE right in #1.

I'm ok if you feel that way and do not want to convince you otherwise.
With so much delay you have all right to complain as long as neither of us gets personal (or other break other community guidelines).
As I said before, with my reply I wanted to show others POV and thereby explain why it might have been not as clear for others.

> You don't need more bug triage at that point. You need a dev to look at the code and
> that did not happen, no matter the effort, here and elsewhere. I believe I even tried
> to get the patch sponsored but nobody dared touching mvo's stuff without an ACK.

As I said in my former post, yes the issue is valid, but not affecting many users, not being in a main package and not yet was coming up to someones attention having the extra bit of driving force to resolve it. All those are aspects of how this happened.

I managed to get it resolved just by the luck of (like you) being very active and thereby knowing some people to ask for favors :-) And sometimes that is what you need to get a stuck ball rolling. I'm sure there are other cases/contacts where you'd be more effective than I would for the same reason :-)

> I'm not sure, but it seems that both you and Miriam mistakenly assume that this bug can
> be triggered by some configuration on the computer where squid-deb-proxy-CLIENT is
> installed. As stated in #7 "this problem occurs whenever there is more than one
> host/IP discovered via avahi." in other words, a certain state of affairs with regards
> to the LAN (plus VPNs) is needed.

On our "request for configuration" I have to beg your pardon for myself and
others. We are coming by so many bugs that our wording (just like your
descriptions in this case) might have been mis-understandable for the same
reasons (we have context in mind that the others do not know).
But without an intention of bikeshedding, that is still a "configuration"...

Np, glad to help - although this time as you said it was more "stepping in" as I wanted to avoid things getting out of control between several people that all only want to help to improve Ubuntu.

> I maintain my assessment of the situation of Ubuntu as stated in #16. I've been
> with Ubuntu since breezy or so. I've been very active in bug triage, I know the 
> processes. I'm happy to back up my rant with facts, if you want to hear.

> I also maintain that this bug ticket and the problem was clearly described including a
> test case in #7 and a clear analysis of where the problem is IN THE CODE right in #1.

I didn't mean to imply "config file foo with entry bar in line X".
Any further detail how to recreate would have helped to clarify.
As always the detail matters, which is part of the reason that the
SRU process encourages literal steps to reproduce.

I've started my own draft (below) on steps how to trigger this based on our
discussions here.
But I think I have managed to fulfill "whenever there is more than one
host/IP discovered via avahi" and it still does not show the reported issue.
This might again be a case of "clear for you but not for everyone else".

#1
# create a VM guest or container with at least three IPv4 adresses
# In the example below I used 4 virtio net in KVM all with DHCP configured
#2
# install prereq packages
$ sudo apt install avahi-utils squid-deb-proxy-client
#3
# check if all are interfaces are configured and avahi probes them all
# (you might need to edit netplan or E/N/I to e.g. dhcp on all of them)
$ avahi-browse -kprtf _apt_proxy._tcp
+;enp9s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+;enp9s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
+;enp9s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+;enp8s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+;enp8s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
+;enp8s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+;enp7s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+;enp7s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
+;enp7s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+;enp1s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+;enp1s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
+;enp1s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
+;lo;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local
=;enp8s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local;Keschdeichel.local;192.168.122.1;3142;
=;enp9s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local;Keschdeichel.local;192.168.122.1;3142;
=;enp7s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local;Keschdeichel.local;192.168.122.1;3142;
=;enp1s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local;Keschdeichel.local;192.168.122.1;3142;
=;enp9s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;fe80::5054:ff:fe3a:53e7;8000;
=;enp8s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;fe80::5054:ff:fe73:b27d;8000;
=;enp7s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;fe80::5054:ff:fe3a:53e7;8000;
=;enp1s0;IPv6;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;fe80::5054:ff:fe4e:2923;8000;
=;enp9s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;192.168.122.125;8000;
=;enp8s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;192.168.122.202;8000;
=;enp7s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;192.168.122.186;8000;
=;enp1s0;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;192.168.122.42;8000;
=;lo;IPv4;Squid\032deb\032proxy\032on\032i-deb-proxy;_apt_proxy._tcp;local;i-deb-proxy.local;127.0.0.1;8000;
#4
# run apt-avahi-discover
$ sudo /usr/share/squid-deb-proxy-client/apt-avahi-discover

I have further looked into it since - as I said - I believe I should already
be at the "whenever there is more than one host/IP discovered via avahi" stage.
In this case recreating the parsing that apt-avahi-discover internally does
leads to:

$ avahi-browse -kprtf _apt_proxy._tcp | grep '^=' | cut -d";" -f 8-9 | grep -v '::'
Failed to resolve service 'apt-cacher-ng proxy on Keschdeichel' of type '_apt_proxy._tcp' in domain 'local': Timeout reached
Failed to resolve service 'apt-cacher-ng proxy on Keschdeichel' of type '_apt_proxy._tcp' in domain 'local': Timeout reached
Failed to resolve service 'apt-cacher-ng proxy on Keschdeichel' of type '_apt_proxy._tcp' in domain 'local': Timeout reached
Failed to resolve service 'apt-cacher-ng proxy on Keschdeichel' of type '_apt_proxy._tcp' in domain 'local': Timeout reached
apt-cacher-ng\032proxy\032on\032Keschdeichel;192.168.122.1;3142
Squid\032deb\032proxy\032on\032i-deb-proxy;192.168.122.125;8000
apt-cacher-ng\032proxy\032on\032Keschdeichel;192.168.122.1;3142
Squid\032deb\032proxy\032on\032i-deb-proxy;192.168.122.202;8000
apt-cacher-ng\032proxy\032on\032Keschdeichel;192.168.122.1;3142
Squid\032deb\032proxy\032on\032i-deb-proxy;192.168.122.186;8000
apt-cacher-ng\032proxy\032on\032Keschdeichel;192.168.122.1;3142
Squid\032deb\032proxy\032on\032i-deb-proxy;192.168.122.42;8000
Squid\032deb\032proxy\032on\032i-deb-proxy;127.0.0.1;8000

So in this setup we see the messages that Andreas saw in comment #8.
But not the reported python errors which we are looking for steps to recreate.
Cross-checking bug 1422162 I also have apt-cacher-ng as reported there, but still no fail.

A manual check of it works just fine.
$ curl 192.168.122.1:3142

You said on that other bug "probing the IP:port combination of the n2n
interface shows the port as closed." so I thought I'll continue on that
thought and got to:

# After being announced stop the cacher on the host
$ sudo systemctl stop apt-cacher-ng.service
# Check it is now dead from the guest
$ curl 192.168.122.1:3142
curl: (7) Failed to connect to 192.168.122.1 port 3142: Connection refused
# Check that it is still announced in avahi
$ avahi-browse -kprtf _apt_proxy._tcp | grep '^=' | cut -d";" -f 4,8-9 | grep -v '::'
Failed to resolve service 'apt-cacher-ng proxy on Keschdeichel' of type '_apt_proxy._tcp' in domain 'local': Timeout reached
Failed to resolve service 'apt-cacher-ng proxy on Keschdeichel' of type '_apt_proxy._tcp' in domain 'local': Timeout reached
Failed to resolve service 'apt-cacher-ng proxy on Keschdeichel' of type '_apt_proxy._tcp' in domain 'local': Timeout reached
Failed to resolve service 'apt-cacher-ng proxy on Keschdeichel' of type '_apt_proxy._tcp' in domain 'local': Timeout reached
apt-cacher-ng\032proxy\032on\032Keschdeichel;192.168.122.1;3142
apt-cacher-ng\032proxy\032on\032Keschdeichel;192.168.122.1;3142
apt-cacher-ng\032proxy\032on\032Keschdeichel;192.168.122.1;3142
apt-cacher-ng\032proxy\032on\032Keschdeichel;192.168.122.1;3142
Squid\032deb\032proxy\032on\032i-deb-proxy;192.168.122.125;8000
Squid\032deb\032proxy\032on\032i-deb-proxy;192.168.122.202;8000
Squid\032deb\032proxy\032on\032i-deb-proxy;192.168.122.186;8000
Squid\032deb\032proxy\032on\032i-deb-proxy;192.168.122.42;8000
Squid\032deb\032proxy\032on\032i-deb-proxy;127.0.0.1;8000
# Now run apt-avahi-discover which shows the python errors bleeding into the
# output even with stderr redirected
$ /usr/share/squid-deb-proxy-client/apt-avahi-discover 2>/dev/null
error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.122.1', 3142): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.9/asyncore.py|read|83] [/usr/lib/python3.9/asyncore.py|handle_read_event|417] [/usr/lib/python3.9/asyncore.py|handle_connect_event|425])
error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.122.1', 3142): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.9/asyncore.py|read|83] [/usr/lib/python3.9/asyncore.py|handle_read_event|417] [/usr/lib/python3.9/asyncore.py|handle_connect_event|425])
error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.122.1', 3142): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.9/asyncore.py|read|83] [/usr/lib/python3.9/asyncore.py|handle_read_event|417] [/usr/lib/python3.9/asyncore.py|handle_connect_event|425])
error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.122.1', 3142): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.9/asyncore.py|read|83] [/usr/lib/python3.9/asyncore.py|handle_read_event|417] [/usr/lib/python3.9/asyncore.py|handle_connect_event|425])
http://192.168.122.42:8000/

For the protection of all the helpful people that looked into the case so far,
this was IMHO not "clear to everyone" from the descriptions so far.
I don't want to convince you Rolf, just to state that there at least could
be different POVs on this.

Looking forward gladly I now think we finally have all that we need in
place. I have pushed my test steps up to the bug description where it is
recommended to be and later required for the SRU.

Miriam has already kindly offered to then drive this into SRUs for the active
releases (thanks to her for that!) and I'll therefore assign it to her.
Let us hope to get this into impish before it is too frozen for the release to
not further delay this.

Looking forward to work with all of you in many more cases that are ahead of us
and together we will make things better a little bit every time.

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2021-10-05:

#21

@Miriam - please consider applying [1] to impish and later on the same for the SRUs.
Let me know if the test steps that I created based on all the discussions would not work for you.

This can then, down the road become a sync again once there is 0.8.16 released.

[1]: https://github.com/mvo5/squid-deb-proxy/commit/604ba3f98beff25a8fd51783d3ffc4db5e987dab

Changed in squid-deb-proxy (Ubuntu):
assignee:	nobody → Miriam España Acebal (mirespace)
tags:	added: server-next
Changed in squid-deb-proxy (Ubuntu Bionic):
assignee:	nobody → Miriam España Acebal (mirespace)
Changed in squid-deb-proxy (Ubuntu Focal):
assignee:	nobody → Miriam España Acebal (mirespace)
Changed in squid-deb-proxy (Ubuntu Hirsute):
assignee:	nobody → Miriam España Acebal (mirespace)
no longer affects:	python2.7 (Ubuntu)
no longer affects:	python2.7 (Ubuntu Bionic)
no longer affects:	python2.7 (Ubuntu Focal)
no longer affects:	python2.7 (Ubuntu Hirsute)

Christian Ehrhardt  (paelzer) on 2021-10-05

summary:

- "uncaptured python exception"
+ python exceptions bleeding into stdout

Miriam España Acebal (mirespace) on 2021-10-06

Changed in squid-deb-proxy (Ubuntu Impish):
status:	Confirmed → In Progress

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2021-10-06:

#22

Download full text (3.5 KiB)

Testing in Impish without extra network interfaces:

# works
$ sudo apt install avahi-utils squid-deb-proxy-client
$ avahi-browse -kprtf _apt_proxy._tcp
+;enp1s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
=;enp1s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local;Keschdeichel.local;192.168.122.1;3142;
$ /usr/share/squid-deb-proxy-client/apt-avahi-discover
http://192.168.122.1:3142/

# break it in the host by disabling cacher
$ systemctl stop apt-cacher-ng.service
# ensure it is gone
$ curl 192.168.122.1:3142

# check the output now
# redirect stderr to show it is not gone
$ /usr/share/squid-deb-proxy-client/apt-avahi-discover 2>/dev/null
error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.122.1', 3142): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.9/asyncore.py|read|83] [/usr/lib/python3.9/asyncore.py|handle_read_event|417] [/usr/lib/python3.9/asyncore.py|handle_connect_event|425])

Upgrade:
ubuntu@i-deb-proxy2:~$ sudo apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  accountsservice language-selector-common libaccountsservice0 net-tools
Use 'sudo apt autoremove' to remove them.
The following packages have been kept back:
  libgirepository-1.0-1 libglib2.0-0 libglib2.0-bin libp11-kit0 libpython3.9
  libpython3.9-minimal libpython3.9-stdlib python3-cffi-backend python3-gi python3.9
  python3.9-minimal
The following packages will be upgraded:
  squid-deb-proxy-client
1 upgraded, 0 newly installed, 0 to remove and 11 not upgraded.
Need to get 9124 B of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] Y
Get:1 http://ppa.launchpad.net/mirespace/impish-squid-deb-proxy-lp1505670-apt-avahi-discover/ubuntu impish/main amd64 squid-deb-proxy-client all 0.8.15+nmu1ubuntu1.1~ppa-mirespace [9124 B]
Fetched 9124 B in 1s (7007 B/s)
(Reading database ... 95211 files and directories currently installed.)
Preparing to unpack .../squid-deb-proxy-client_0.8.15+nmu1ubuntu1.1~ppa-mirespace_all.deb ...
Unpacking squid-deb-proxy-client (0.8.15+nmu1ubuntu1.1~ppa-mirespace) over (0.8.15+nmu1) ...
Setting up squid-deb-proxy-client (0.8.15+nmu1ubuntu1.1~ppa-mirespace) ...
Scanning processes...
Scanning candidates...
Scanning linux images...

Restarting services...
Service restarts being deferred:
/etc/needrestart/restart.d/dbus.service
systemctl restart <email address hidden>
systemctl restart networkd-dispatcher.service
systemctl restart systemd-logind.service
systemctl restart unattended-upgrades.service

No containers need to be restarted.

User sessions running outdated binaries:
ubuntu @ session #1: sshd[1208,1305]
ubuntu @ user manager service: systemd[1211]

# now no output blee...

Testing in Impish without extra network interfaces:

# break it in the host by disabling cacher
$ systemctl stop apt-cacher-ng.service
# ensure it is gone
$ curl 192.168.122.1:3142

Upgrade:
ubuntu@i-deb-proxy2:~$ sudo apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  accountsservice language-selector-common libaccountsservice0 net-tools
Use 'sudo apt autoremove' to remove them.
The following packages have been kept back:
  libgirepository-1.0-1 libglib2.0-0 libglib2.0-bin libp11-kit0 libpython3.9
  libpython3.9-minimal libpython3.9-stdlib python3-cffi-backend python3-gi python3.9
  python3.9-minimal
The following packages will be upgraded:
  squid-deb-proxy-client
1 upgraded, 0 newly installed, 0 to remove and 11 not upgraded.
Need to get 9124 B of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] Y
Get:1 http://ppa.launchpad.net/mirespace/impish-squid-deb-proxy-lp1505670-apt-avahi-discover/ubuntu impish/main amd64 squid-deb-proxy-client all 0.8.15+nmu1ubuntu1.1~ppa-mirespace [9124 B]
Fetched 9124 B in 1s (7007 B/s)            
(Reading database ... 95211 files and directories currently installed.)
Preparing to unpack .../squid-deb-proxy-client_0.8.15+nmu1ubuntu1.1~ppa-mirespace_all.deb ...
Unpacking squid-deb-proxy-client (0.8.15+nmu1ubuntu1.1~ppa-mirespace) over (0.8.15+nmu1) ...
Setting up squid-deb-proxy-client (0.8.15+nmu1ubuntu1.1~ppa-mirespace) ...
Scanning processes...                                                                          
Scanning candidates...                                                                         
Scanning linux images...

Restarting services...
Service restarts being deferred:
 /etc/needrestart/restart.d/dbus.service
 systemctl restart getty@tty1.service
 systemctl restart networkd-dispatcher.service
 systemctl restart systemd-logind.service
 systemctl restart unattended-upgrades.service

No containers need to be restarted.

User sessions running outdated binaries:
 ubuntu @ session #1: sshd[1208,1305]
 ubuntu @ user manager service: systemd[1211]

# now no output bleeding through
$ /usr/share/squid-deb-proxy-client/apt-avahi-discover 2>/dev/null

# actually since there is no proxy left there is juts nothing now in this setup
/usr/share/squid-deb-proxy-client/apt-avahi-discover

# But as soon as the cacher is back up it works:
$ /usr/share/squid-deb-proxy-client/apt-avahi-discover
http://192.168.122.1:3142/

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2021-10-06:

#23

After the test (all worked) and sponsored it to impish.
Let us hope it slips in before the freeze happens.

SRUs from there will again be prepared by Miriam.

Revision history for this message

Launchpad Janitor (janitor) wrote on 2021-10-06:

#24

This bug was fixed in the package squid-deb-proxy - 0.8.15+nmu1ubuntu1

---------------
squid-deb-proxy (0.8.15+nmu1ubuntu1) impish; urgency=medium

  [ Michael Vogt ]
  * apt-avahi-discover: use syslog for logging
    in AptAvahiClient, thanks to Jason Pepas
    (<email address hidden>).
    (LP: #1505670).

-- Miriam España Acebal <email address hidden> Tue, 05 Oct 2021 11:23:59 +0200

Changed in squid-deb-proxy (Ubuntu Impish):
status:	In Progress → Fix Released

Miriam España Acebal (mirespace) on 2021-10-15

Changed in squid-deb-proxy (Ubuntu Bionic):
status:	New → In Progress
Changed in squid-deb-proxy (Ubuntu Focal):
status:	New → In Progress
Changed in squid-deb-proxy (Ubuntu Hirsute):
status:	New → In Progress

Miriam España Acebal (mirespace) on 2021-10-15

description:

updated

Miriam España Acebal (mirespace) on 2021-10-18

description:	updated
description:	updated

Miriam España Acebal (mirespace) on 2021-10-26

description:

updated

Revision history for this message

Robie Basak (racb) wrote on 2021-10-27:

#25

Following discussion, I'm adjusting the Bionic package version string from 0.8.14ubuntu1 to 0.8.14ubuntu0.18.04.1 to avoid any potential conflict with a future ESM update to this package in Xenial.

Changed in squid-deb-proxy (Ubuntu Hirsute):
status:	In Progress → Fix Committed
tags:	added: verification-needed verification-needed-hirsute

Revision history for this message

Robie Basak (racb) wrote on 2021-10-27: Please test proposed package

#26

Hello Rolf, or anyone else affected,

Accepted squid-deb-proxy into hirsute-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/squid-deb-proxy/0.8.15ubuntu0.21.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-hirsute to verification-done-hirsute. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-hirsute. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in squid-deb-proxy (Ubuntu Focal):
status:	In Progress → Fix Committed
tags:	added: verification-needed-focal

Revision history for this message

Robie Basak (racb) wrote on 2021-10-27:

#27

Hello Rolf, or anyone else affected,

Accepted squid-deb-proxy into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/squid-deb-proxy/0.8.15ubuntu0.20.04.1 in a few hours, and then in the -proposed repository.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in squid-deb-proxy (Ubuntu Bionic):
status:	In Progress → Fix Committed
tags:	added: verification-needed-bionic

Revision history for this message

Robie Basak (racb) wrote on 2021-10-27:

#28

Hello Rolf, or anyone else affected,

Accepted squid-deb-proxy into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/squid-deb-proxy/0.8.14ubuntu0.18.04.1 in a few hours, and then in the -proposed repository.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Mathew Hodson (mhodson) on 2021-10-31

Changed in squid-deb-proxy (Ubuntu Bionic):
importance:	Undecided → Low
Changed in squid-deb-proxy (Ubuntu Focal):
importance:	Undecided → Low
Changed in squid-deb-proxy (Ubuntu Hirsute):
importance:	Undecided → Low

Mathew Hodson (mhodson) on 2021-10-31

Changed in squid-deb-proxy (Ubuntu Trusty):
status:	New → Won't Fix
importance:	Undecided → Low
Changed in squid-deb-proxy (Ubuntu Xenial):
status:	New → Won't Fix
importance:	Undecided → Low

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2021-11-04:

#29

Bionic
Check after cacher is down in the host

+;enp8s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
=;enp8s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local;Keschdeichel.local;192.168.122.1;3142;

ubuntu@b-deb-proxy:~$ curl 192.168.122.1:3142
curl: (7) Failed to connect to 192.168.122.1 port 3142: Connection refused

ubuntu@b-deb-proxy:~$ /usr/share/squid-deb-proxy-client/apt-avahi-discover 2>/dev/null
error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.122.1', 3142): 9223372036854775807 (<class 'socket.error'>:[Errno 111] Connection refused [/usr/lib/python2.7/asyncore.py|read|83] [/usr/lib/python2.7/asyncore.py|handle_read_event|446] [/usr/lib/python2.7/asyncore.py|handle_connect_event|454])

Upgrade

ubuntu@b-deb-proxy:~$ sudo apt install squid-deb-proxy-client
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
squid-deb-proxy-client
1 upgraded, 0 newly installed, 0 to remove and 17 not upgraded.
Need to get 4820 B of archives.
After this operation, 2048 B of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu bionic-proposed/universe amd64 squid-deb-proxy-client all 0.8.14ubuntu0.18.04.1 [4820 B]
Fetched 4820 B in 0s (55.6 kB/s)
(Reading database ... 91938 files and directories currently installed.)
Preparing to unpack .../squid-deb-proxy-client_0.8.14ubuntu0.18.04.1_all.deb ...
Unpacking squid-deb-proxy-client (0.8.14ubuntu0.18.04.1) over (0.8.14) ...
Setting up squid-deb-proxy-client (0.8.14ubuntu0.18.04.1) ...

Test with new version

ubuntu@b-deb-proxy:~$ /usr/share/squid-deb-proxy-client/apt-avahi-discover 2>/dev/null

No more errors bleed into the output, mark verified

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2021-11-04:

#30

Focal
Check after cacher is down in the host

+;enp8s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
+;enp7s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
+;enp1s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local
=;enp8s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local;Keschdeichel.local;192.168.122.1;3142;
=;enp7s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local;Keschdeichel.local;192.168.122.1;3142;
=;enp1s0;IPv4;apt-cacher-ng\032proxy\032on\032Keschdeichel;_apt_proxy._tcp;local;Keschdeichel.local;192.168.122.1;3142;

ubuntu@f-deb-proxy:~$ curl 192.168.122.1:3142
curl: (7) Failed to connect to 192.168.122.1 port 3142: Connection refused

ubuntu@f-deb-proxy:~$ /usr/share/squid-deb-proxy-client/apt-avahi-discover 2>/dev/null
error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.122.1', 3142): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.8/asyncore.py|read|83] [/usr/lib/python3.8/asyncore.py|handle_read_event|417] [/usr/lib/python3.8/asyncore.py|handle_connect_event|425])
error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.122.1', 3142): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.8/asyncore.py|read|83] [/usr/lib/python3.8/asyncore.py|handle_read_event|417] [/usr/lib/python3.8/asyncore.py|handle_connect_event|425])
error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.122.1', 3142): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.8/asyncore.py|read|83] [/usr/lib/python3.8/asyncore.py|handle_read_event|417] [/usr/lib/python3.8/asyncore.py|handle_connect_event|425])

Upgrade

ubuntu@f-deb-proxy:~$ sudo apt install squid-deb-proxy-client
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
squid-deb-proxy-client
1 upgraded, 0 newly installed, 0 to remove and 16 not upgraded.
Need to get 4948 B of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu focal-proposed/universe amd64 squid-deb-proxy-client all 0.8.15ubuntu0.20.04.1 [4948 B]
Fetched 4948 B in 1s (4189 B/s)
(Reading database ... 94694 files and directories currently installed.)
Preparing to unpack .../squid-deb-proxy-client_0.8.15ubuntu0.20.04.1_all.deb ...
Unpacking squid-deb-proxy-client (0.8.15ubuntu0.20.04.1) over (0.8.15) ...
Setting up squid-deb-proxy-client (0.8.15ubuntu0.20.04.1) ...

Test with new version

ubuntu@f-deb-proxy:~$ /usr/share/squid-deb-proxy-client/apt-avahi-discover 2>/dev/null

No more errors bleed into the output, mark verified

Focal
Check after cacher is down in the host

ubuntu@f-deb-proxy:~$ curl  192.168.122.1:3142
curl: (7) Failed to connect to 192.168.122.1 port 3142: Connection refused

Upgrade

ubuntu@f-deb-proxy:~$ sudo apt install squid-deb-proxy-client
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be upgraded:
  squid-deb-proxy-client
1 upgraded, 0 newly installed, 0 to remove and 16 not upgraded.
Need to get 4948 B of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu focal-proposed/universe amd64 squid-deb-proxy-client all 0.8.15ubuntu0.20.04.1 [4948 B]
Fetched 4948 B in 1s (4189 B/s)            
(Reading database ... 94694 files and directories currently installed.)
Preparing to unpack .../squid-deb-proxy-client_0.8.15ubuntu0.20.04.1_all.deb ...
Unpacking squid-deb-proxy-client (0.8.15ubuntu0.20.04.1) over (0.8.15) ...
Setting up squid-deb-proxy-client (0.8.15ubuntu0.20.04.1) ...

Test with new version

ubuntu@f-deb-proxy:~$ /usr/share/squid-deb-proxy-client/apt-avahi-discover 2>/dev/null

No more errors bleed into the output, mark verified

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2021-11-04:

#31

Download full text (3.8 KiB)

Hirsute
Check after cacher is down in the host

ubuntu@h-deb-proxy:~$ curl 192.168.122.1:3142
curl: (7) Failed to connect to 192.168.122.1 port 3142: Connection refused

ubuntu@h-deb-proxy:~$ /usr/share/squid-deb-proxy-client/apt-avahi-discover 2>/dev/null
error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.122.1', 3142): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.9/asyncore.py|read|83] [/usr/lib/python3.9/asyncore.py|handle_read_event|417] [/usr/lib/python3.9/asyncore.py|handle_connect_event|425])
error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.122.1', 3142): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.9/asyncore.py|read|83] [/usr/lib/python3.9/asyncore.py|handle_read_event|417] [/usr/lib/python3.9/asyncore.py|handle_connect_event|425])
error: uncaptured python exception, closing channel <AptAvahiClient> ('192.168.122.1', 3142): 9223372036854775807 (<class 'ConnectionRefusedError'>:[Errno 111] Connection refused [/usr/lib/python3.9/asyncore.py|read|83] [/usr/lib/python3.9/asyncore.py|handle_read_event|417] [/usr/lib/python3.9/asyncore.py|handle_connect_event|425])

Upgrade

ubuntu@h-deb-proxy:~$ sudo apt install squid-deb-proxy-client
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following package was automatically installed and is no longer required:
net-tools
Use 'sudo apt autoremove' to remove it.
The following packages will be upgraded:
squid-deb-proxy-client
1 upgraded, 0 newly installed, 0 to remove and 14 not upgraded.
Need to get 4876 B of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu hirsute-proposed/universe amd64 squid-deb-proxy-client all 0.8.15ubuntu0.21.04.1 [4876 B]
Fetched 4876 B in 1s (4131 B/s)
(Reading database ... 99104 files and directories currently installed.)
Preparing to unpack .../squid-deb-proxy-client_0.8.15ubuntu0.21.04.1_all.deb ...
Unpacking squid-deb-proxy-client (0.8.15ubuntu0.21.04.1) over (0.8.15build1) ...
Setting up squid-deb-proxy-client (0.8.15ubuntu0.21.04.1) ...
Scanning processes...
Scanning candidates... ...

Hirsute
Check after cacher is down in the host

ubuntu@h-deb-proxy:~$ curl  192.168.122.1:3142
curl: (7) Failed to connect to 192.168.122.1 port 3142: Connection refused

Upgrade

ubuntu@h-deb-proxy:~$ sudo apt install squid-deb-proxy-client
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following package was automatically installed and is no longer required:
  net-tools
Use 'sudo apt autoremove' to remove it.
The following packages will be upgraded:
  squid-deb-proxy-client
1 upgraded, 0 newly installed, 0 to remove and 14 not upgraded.
Need to get 4876 B of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu hirsute-proposed/universe amd64 squid-deb-proxy-client all 0.8.15ubuntu0.21.04.1 [4876 B]
Fetched 4876 B in 1s (4131 B/s)            
(Reading database ... 99104 files and directories currently installed.)
Preparing to unpack .../squid-deb-proxy-client_0.8.15ubuntu0.21.04.1_all.deb ...
Unpacking squid-deb-proxy-client (0.8.15ubuntu0.21.04.1) over (0.8.15build1) ...
Setting up squid-deb-proxy-client (0.8.15ubuntu0.21.04.1) ...
Scanning processes...                                                                                                                                                                          
Scanning candidates...                                                                                                                                                                         
Scanning linux images...

Restarting services...
Service restarts being deferred:
 /etc/needrestart/restart.d/dbus.service
 systemctl restart systemd-logind.service
 systemctl restart unattended-upgrades.service

No containers need to be restarted.

User sessions running outdated binaries:
 ubuntu @ session #1: sshd[759]
 ubuntu @ user manager service: systemd[762]

Test with new version

ubuntu@h-deb-proxy:~$ /usr/share/squid-deb-proxy-client/apt-avahi-discover 2>/dev/null

No more errors bleed into the output, mark verified

tags:

added: verification-done verification-done-bionic verification-done-focal verification-done-hirsute
removed: verification-needed verification-needed-bionic verification-needed-focal verification-needed-hirsute

Revision history for this message

Miriam España Acebal (mirespace) wrote on 2021-11-04:

#32

Thanks a lot, Christian, for the verification and all the previous help on this!

Revision history for this message

Launchpad Janitor (janitor) wrote on 2021-11-04:

#33

This bug was fixed in the package squid-deb-proxy - 0.8.15ubuntu0.21.04.1

---------------
squid-deb-proxy (0.8.15ubuntu0.21.04.1) hirsute; urgency=medium

  * apt-avahi-discover: write errors to stderr instead
    of stdout so that stdout can be captured correctly.
    Thanks to <email address hidden>. Note that this is
    being fixed differently (stderr and not syslog)
    in the stable releases. LP: #1505670.

-- Miriam España Acebal <email address hidden> Tue, 05 Oct 2021 13:23:08 +0200

Changed in squid-deb-proxy (Ubuntu Hirsute):
status:	Fix Committed → Fix Released

Revision history for this message

Brian Murray (brian-murray) wrote on 2021-11-04: Update Released

#34

The verification of the Stable Release Update for squid-deb-proxy has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message

Launchpad Janitor (janitor) wrote on 2021-11-04:

#35

This bug was fixed in the package squid-deb-proxy - 0.8.15ubuntu0.20.04.1

---------------
squid-deb-proxy (0.8.15ubuntu0.20.04.1) focal; urgency=medium

-- Miriam España Acebal <email address hidden> Thu, 14 Oct 2021 13:41:22 +0200

Changed in squid-deb-proxy (Ubuntu Focal):
status:	Fix Committed → Fix Released

Revision history for this message

Launchpad Janitor (janitor) wrote on 2021-11-04:

#36

This bug was fixed in the package squid-deb-proxy - 0.8.14ubuntu0.18.04.1

---------------
squid-deb-proxy (0.8.14ubuntu0.18.04.1) bionic; urgency=medium

-- Miriam España Acebal <email address hidden> Thu, 14 Oct 2021 16:48:09 +0200

Changed in squid-deb-proxy (Ubuntu Bionic):
status:	Fix Committed → Fix Released

Report a bug

This report contains Public information

Everyone can see this information.

Duplicates of this bug

Bug #1422162

You are

Subscribing...

Edit bug mail

Other bug subscribers

Patches

Add patch

Remote bug watches

Bug watches keep track of this bug in other bug trackers.

Ubuntusquid-deb-proxy package

python exceptions bleeding into stdout

Bug Description

Related branches

Duplicates of this bug

Other bug subscribers

Patches

Remote bug watches

Ubuntu
squid-deb-proxy package