Dear Maintainer,

while running autopkgtests for dpkg, for Debian LTS bullseye, on
debusine.debian.net, I noticed that `test-func-root` failed [1].

The issue is that `mknod` doesn't work in the test environment:
debusine.debian.net runs autopkgtest with the Incus-LXC backend, and one
can't create devices in this environment.

In contrast, this test passes on ci.debian.net, which runs autopkgtest
with the plain LXC backend. However that won't last, ci.debian.net will
switch to Incus-LXC at some point in the future (before forky is out).

I opened a issue to discuss this with the support team behind
debusine.debian.net at [2]. Antonio chimed in regarding ci.debian.net,
saying:

So it seems to me that dpkg should do one of these:

Option 1

Add isolation-machine restriction for this test, and coordinate with
ci.debian.net so that dpkg is added to the list of packages that are
allowed to run on a VM backend. It also means that for architectures
that don't provide a VM backend, the test will be skipped -- is that
acceptable?

Option 2

Do not conflate "needs-root" with "I can create device", which is not
necessarily true. The test suite could be adjusted to check whether it's
possible to create a device, and if it's not possible, skip those few
tests that need this capability.

I can provide a patch for Option 2 if you're interested.

Best,

Arnaud

Hi!

Ah, thanks for handling this!

This seems too cumbersome.

I think this would be better, and more resilient in general from an
upstream PoV regardless of the location the tests are executed by
downstreams (random CI systems etc). So a patch would be very welcome.

(I assume that doing this in make will be a pain, but the functional
test suite should eventually get rewritten in autotest, which will make
it nicer to deal with.)

Thanks,
Guillem

Hi!

I'm assuming that you did not have the time to look into this further,
so I'll start preparing one, but otherwise let me know if you were
still working on this!

I think this is an unrelated, expected failure from the test suite, and
the root for this report is what Arnaud had reported earlier.

As I mentioned to Arnaud above, I'd prefer to disable the specific tests
in that scenario instead of requiring a special case for dpkg, and a more
heavy method to run the tests.

Thanks,
Guillem

Hi!

In the end I went with a trivial solution, requiring explicitly enabling
these tests. Once the test suite gets rewritten it can be switched to be
autodetected, but for now this should be good enough.

I'm attaching what I ended up with. Tested on a sid chroot, with
/usr/bin/mknod removed, to simulate "no mknod allowed". :)

Thanks,
Guillem