On Thu, Aug 15, 2024 at 11:25:46AM -0300, Andreas Hasenack wrote:
> Hello,
> [...]
> > Thanks for raising this! What a surprise - I hadn't realised this
> > problem. But I'm not sure about the proposed patch: jupyter-client
> > itself calls ifconfig (in jupyter_client/localinterfaces.py), so it
> > might be better to have this dependency be part of the binary package
> > itself rather than just part of the test suite.
> >
> > If this isn't needed (have a read of the code in that file - it will
> > not fail is ifconfig is not found, just that some functionality will
> > be lost), and it's just that the test is failing, then your patch
> > would be fine.
>
> Ah, good catch. Looks the code tries 4 different approaches, in order:
> - netifaces, provided by python3-netifaces (not a Depends)
> - /sbin/ip from iproute2, also not a dependency, and in ubuntu
> iproute2 is "important"
> - /sbin/ifconfig (this bug)
> - gethostbyname, provided by /usr/lib/python3.12/socket.py, packaged
> in libpython3.12-minimal, which will be installed because jupyter is
> python
>
> I guess the last one will always work, and even that one has a
> fallback of returning 127.0.0.1
>
> Maybe a Recommends for python3-netifaces, which seems the less
> error-prone method, as it doesn't involve any parsing of command
> output (ip or ifconfig)?
Except that python3-netifaces is abandoned upstream, so I don't really
want to add new dependencies on it. :/
There is a package which is maintained (if struggling) which could be
used instead of netiface: psutil. But that should be an upstream
change rather than a Debian-local change.
> The test seems to be expecting ifconfig, though. Unsure if it's a side
> effect of not having found any of the other alternatives.
No, the test explicitly tests that the ifconfig method works:
if sys.platform == "linux":
localinterfaces._load_ips_ip()
localinterfaces._load_ips_ifconfig()
Best wishes,
Julian
