Hello Guillem,
On 19/08/2026 18:03, Guillem Jover wrote:
On Wed, 2026-08-19 at 11:44:14 +0200, Guillem Jover wrote:
On Fri, 2026-07-17 at 04:59:34 +0200, Guillem Jover wrote:
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!
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 for handling that, and sorry for being so late to reply.
On my side, I did some work on dynamic discovery of whether mknod works,
it boiled down to adding the following check in tests/Test.mk:
```
+CAN_MAKE_DEVICES := $(shell $(BEROOT) mknod /dev/dpkg-test c 1 3
>/dev/null 2>&1 && echo 1 || echo 0; $(BEROOT) rm -f /dev/dpkg-test;)
```
I can try to finish this work and propose a patch, if you ask me to. But
honestly, I'm happy with your patch, and I'm not even sure that I'm
taking the right approach here. So it's up to you.
On another note: do you think you can include your patch in the next
point release(s) of dpkg for older suites? I tried and it applies
cleanly up to bullseye. It fails for buster, didn't check why.
For context: on the debusine.debian.net instance, the dpkg's autopkgtest
for amd64 is in the green, because we configured it to run in a VM.
However there are no VM for arm64 or ppc64el, so the tests run in
incus-lxc, and thus fail, for those archs. I'm just trying to keep the
dpkg autopkgtests in the green, given it's such a fundamental package.
Best,
Arnaud
