Bug#1099017: debci: apt-listbugs autopkgtest fails on riscv64: /usr/bin/auto-apt-proxy: 176: avahi-browse: not found

Discussion:

Add Reply

Paul Gevers

2025-02-27 11:10:02 UTC

Hi,

It seems that the tests that need Internet access (and are marked as
302s /usr/bin/auto-apt-proxy: 176: avahi-browse: not found
303s E: Failed to open TCP connection to :80 (Connection refused - connect(2) for "" port 80)
303s E: Exiting with error
It should be noted that apt-listbugs will attempt to run an auto proxy
detect command, if one is found in APT configuration
( acquire::http::proxy-auto-detect ).
I guess the testbed has 'auto-apt-proxy' installed, but is it working
correctly?

Unfortunately, not all our riscv64 workers are configured in the same
way, as in one location we have a dedicated local proxy, and in the
other we don't. All the workers nodes in Shanghai have a proxy
configured and I think autopkgtest picks that up and installs
auto-apt-proxy in the testbed and that seems to work for the purpose of
downloading packages (I think the warning about avahi-browser is only a
warning). The nodes in Beijing don't have a dedicated proxy and instead
have apt-cacher-ng installed on the node itself. I didn't install
auto-apt-proxy on those nodes because that didn't seem to work (sorry
for not filling a bug report), but autopkgtest on those nodes seemed to
work nicely without it. I'm not sure if auto-apt-proxy gets installed on
those testbeds. I'll test that shortly.

Is there anything wrong in the tests defined in package 'apt-listbugs'?
Is there anything that fails to work in the riscv64 Debian CI testbed?
Is there anything that needs to be fixed anywhere else?

Maybe.

I have re-triggered your test several times and it succeeded once on a
Beijing host, so that should get it out of your way. Thanks for letting
us know.

Paul

Antonio Terceiro

2025-02-27 13:40:02 UTC

Permalink

Hi,

This failure mode ("avahi-browse: not found") is a regression in
auto-apt-proxy 16.2. It should check whether avahi-browser is installed
before using it (as documented). I will upload a fixed version soon.

It should be noted that apt-listbugs will attempt to run an auto proxy
detect command, if one is found in APT configuration
( acquire::http::proxy-auto-detect ).
I guess the testbed has 'auto-apt-proxy' installed, but is it working
correctly?

Unfortunately, not all our riscv64 workers are configured in the same way,
as in one location we have a dedicated local proxy, and in the other we
don't. All the workers nodes in Shanghai have a proxy configured and I think
autopkgtest picks that up and installs auto-apt-proxy in the testbed and
that seems to work for the purpose of downloading packages (I think the
warning about avahi-browser is only a warning). The nodes in Beijing don't
have a dedicated proxy and instead have apt-cacher-ng installed on the node
itself. I didn't install auto-apt-proxy on those nodes because that didn't
seem to work (sorry for not filling a bug report), but autopkgtest on those
nodes seemed to work nicely without it. I'm not sure if auto-apt-proxy gets
installed on those testbeds. I'll test that shortly.

Is there anything wrong in the tests defined in package 'apt-listbugs'?
Is there anything that fails to work in the riscv64 Debian CI testbed?
Is there anything that needs to be fixed anywhere else?

Maybe.
I have re-triggered your test several times and it succeeded once on a
Beijing host, so that should get it out of your way. Thanks for letting us
know.

I think this one is on me.

Simon McVittie

2025-03-04 09:30:01 UTC

Permalink

Post by Antonio Terceiro

It looks as though ci-worker-s390x-01 is also affected by this issue, for
example in <https://ci.debian.net/packages/q/qemu/testing/s390x/58443806/>.
Please could someone with access upgrade that machine or regenerate
its lxc images (I'm not sure which one is the relevant layer) now that
auto-apt-proxy/16.3 has migrated to testing?

Thanks,
smcv