Dear maintainer(s),

I looked at the results of the autopkgtest of your package. I noticed
that it regularly fails, at least on s390x. I triggered 5 runs and 2
failed. I hope I copy/pasted the relevant part below.

Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul

https://ci.debian.net/packages/c/chkrootkit/testing/s390x/74480411/

532s ** FAIL: Testing: all-tests-can-find-something-01 (chkrootkit -p
/tmp/clean) done: FAIL
532s *** FAIL was with config set to:
532s RUN_DAILY=true
532s RUN_DAILY_OPTS='-q'
532s DIFF_MODE=true
532s MAILTO=root
532s
532s *** Reason(s) for failure follows
532s Result: FAIL
532s
532s Missing: ^Checking `sshd'\.\.\.
      INFECTED but disabled$
532s *** Unexpected (unmatched) lines follow (for info):
532s Checking `sshd'...                                          INFECTED
532s erspan0: not promisc and no packet sniffer sockets
532s gre0: not promisc and no packet sniffer sockets
532s gretap0: not promisc and no packet sniffer sockets
532s ip6_vti0: not promisc and no packet sniffer sockets
532s ip6gre0: not promisc and no packet sniffer sockets
532s ip6tnl0: not promisc and no packet sniffer sockets
532s ip_vti0: not promisc and no packet sniffer sockets
532s sit0: not promisc and no packet sniffer sockets
532s tunl0: not promisc and no packet sniffer sockets

I think what is happening is that a running (and unrelated) sshd is
sometimes visible from the testbed and sometimes not (which influences
the output). The autopkgtest wrongly assumed it would be consistent .
i assume different test runners have different settings and that's why
it looks flaky

But i think there's some other issue that needs a bit more
investigating by me (i will loook in the next 2 weeks):
- how can sshd ever be visible from the testbed?
- why doesnt the following test with -q fail in the same way.
- (is the upstream code for seeing if sshd is running correct? )

(nb - add a "ps ax" to the info section at the start of the test to
have more info about the testbed!)

Hi Richard,

Looking at https://ci.debian.net/packages/c/chkrootkit/testing/s390x/
it seems the issue is related to the incus-lxc backend, introduced
after 2026-07-30 22:13:25 UTC. Earlier tests, run on lxc, passed.

Sven

thanks -- looking at
https://wiki.debian.org/ContinuousIntegration/LxcToIncus the lxc backend
incldues sshd (!) it's correctly missing from incus.

except isnt this one
https://ci.debian.net/data/autopkgtest/testing/s390x/c/chkrootkit/74450913/log.gz
is incus and passing. And there's not anything obviously arch-specific
about this -- we should be seeing all the other arch's being equally flaky,
and they dont seem to be.

(if anyone can  reproduce the failure, i would be curious to see what

bash -xv chkrootkit sshd

ps ax | grep sshd

return on a s390 system where it fails)


(But looking further: I dont actually see how the message seen on s390
could ever be produced in a functioning system --- it would need "ps ax
sshd | grep -E sshd" to _fail_, which is never going to happen: the grep
will match its own process in the output of ps  (which is a bug in
chkrootkit - but this is offset by a second bug as the test is backwards...
luckily this only affects systems with a rootkit in sshd..... and there's a
3rd issue in that 'chkrootkit -q sshd' never reports anything ). so
something else is perhaps broken/flaky in s390, but i suspect fixing the
issues in chkrootkit and its tests will probably resolve the failure)