Control: forcemerge 1142100 1144781 Hi!
On Fri, 2026-07-17 at 04:59:34 +0200, Guillem Jover wrote: > On Wed, 2026-07-15 at 17:13:29 +0700, Arnaud Rebillout wrote: > > Source: dpkg > > Severity: normal > > 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: > > > > > Yes, ci.debian.net currently uses privileged containers, > > > and that will not be the case very soon. > > > > > > "Interacting with the kernel", of which mknod is an > > > example of, is already the main documented use case > > > for the "isolation-machine" restriction. The fact that > > > it works today is an accident, not by design. > > Ah, thanks for handling this! > > > 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? > > This seems too cumbersome. > > > 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. > > 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.) 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! On Tue, 2026-08-18 at 20:19:47 -0300, Antonio Terceiro wrote: > Source: dpkg > Version: 1.23.7 > Severity: important > Justification: fails autopkgtest on Debian CI infrastructure > Tags: forky sid > User: [email protected] > Usertags: lxc > Debian CI is switching away from lxc containers in favor of incus Containers. > This is motivated by security concerns from us; incus is based on lxc, but > orchestrates containers substantially different: containers are not privileged > (so root in the container is not uid 0 outside of it, and incus imposes a > stricter isolation from the host system. > > dpkg passes its tests under lxc, but fails under incus. > The relevant part of the failure is (hopefully): > > > D000010: deferred extract of '/.'? > > D000001: process_archive(): updating info directory > > D001000: infodb foreach metadata file '.' > > D001000: infodb foreach metadata file '..' > > D001000: infodb foreach metadata file 'pkg-depends.list' > > D002000: infodb foreach file this pkg > > D001000: infodb foreach metadata file 'format' > > D000002: pkg_infodb_update(): tmp.ci script/file '.' contains dot > > D000002: pkg_infodb_update(): tmp.ci script/file '..' contains dot > > D000002: pkg_infodb_update(): tmp.ci script/file > > '/tmp/autopkgtest.BIG8g4/autopkgtest_tmp/db/tmp.ci/control' is control > > D000001: generating infodb digest file for pkg-depends:all > > D000010: path_remove_tree(): > > '/tmp/autopkgtest.BIG8g4/autopkgtest_tmp/db/tmp.ci' > > D000010: path_remove_tree(): running rm -rf > > '/tmp/autopkgtest.BIG8g4/autopkgtest_tmp/db/tmp.ci' > > D000010: path_remove_tree(): > > '/tmp/autopkgtest.BIG8g4/autopkgtest_tmp/db/reassemble.deb' > > D000001: process queue pkg pkg-depends:all queue.len 0 progress 1, try 1 > > D000040: checking dependencies of pkg-depends:all (- <none>) > > D000400: checking group ... > > D000400: checking possibility -> pkg-real > > D000400: not installed > > D000400: returning 0 > > D000400: found 0 > > D000400: found 0 matched 0 possfixbytrig - > > D000040: ok 0 msgs >> pkg-depends depends on pkg-real; however: > > Package pkg-real is not installed. > > << > > D000040: checking Breaks > > dpkg: dependency problems prevent configuration of pkg-depends: > > pkg-depends depends on pkg-real; however: > > Package pkg-real is not installed. > > > > dpkg: error processing package pkg-depends (--install): > > dependency problems - leaving unconfigured I think this is an unrelated, expected failure from the test suite, and the root for this report is what Arnaud had reported earlier. > The full autokpgtest logs are available at: > https://ci.debian.net/experiments/8/regressions/ > (please beware of pagination) > > Common types of failure and suggested fixes are being documented at: > https://wiki.debian.org/ContinuousIntegration/LxcToIncus > > Note that for the time being, dpkg is still being tested under lxc to > avoid disturbing its testing migration test results. > > If you decide to add the `isolation-machine` restriction to get this package > tested under qemu, please mention that explicitly when closing this bug (it's > fine to do that only in the package changelog entry that closes the bug) so > that we can configure your package for qemu on ci.debian.net. 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
