Hi, Quoting David Bremner (2024-03-01 14:09:36) > Nilesh Patra <nilesh@debian.org> writes: > > When I want to fix autopkgtests for a package on a particular architecture, > > I currently see no way to run autopkgtests before I dput since porter boxes > > do not provide root access which autopkgtest needs. > > > > Currently I am manually hacking around the test scripts and running the autopkgtests but > > this does not emulate the autopkgtest environment well enough. It also does not work > > well for daemon-like packages for instance. > Related, we wouldn't need to use the porterboxes if the situation for running > autopkgtests locally was better. I disagree. I think even with perfect autopkgtest support I'd want porter boxes because: a) emulation is slow b) there are some bugs for which you want the real hardware to reproduce them c) some arches are a pain or impossible to emulate > I have complained at length on IRC on the difficulties of running > autopkgtests locally on non-amd64 architectures. There surely are rough edges. I recently got [gic-version] fixed to run autopkgtest with qemu on arm64. Are there more bugs on other non-amd64 architectures? [gic-version] https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/239 > There is some tooling to build images for e.g. the qemu backend, but in my > experience it does not work smoothly. I think the autopkgtest maintainers > could use help with improving this tooling. Agreed. The tooling around creating and running qemu images with the autopkgtest qemu backend is not ideal. I'm personally interested in having this work so I'd love to hear about the bugs you found related to making autopkgtest support running inside qemu virtual machines. There currently exist several attempts to improve the status quo. One issue with emulation support is making the bootloader work. If the thing you want to test does not care about the bootloader, then using Helmut's debvm might be what you want which is currently being integrated into autopkgtest via [ssh-setup] by Jochen Sprickerhof. I was not happy with the autopkgtest-build-qemu script which contains limitations directly connected with its use of vmdb2 so I rolled my own and called it mmdebstrap-autopkgtest-build-qemu which is available since mmdebstrap 1.4.0. It should work for all architectures that have EFI support. If you need to do something on ppc64el I have another script which uses grub ieee1275 instead of EFI booting. I have not managed to get mips to boot. [ssh-setup] https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/237 > Personally I am reluctant to add non-amd64 autopkgtests to packages with the > current state of tooling. I do not consider "upload and find out" an > acceptable debugging strategy. Personally, I found the bigger blocker for autopkgtest not the architecture support but the use of docker or lxc. For my packages, I had to repeatedly use the "upload and find out" strategy because most of my autopktest problems are related to my code working on bare-metal or inside qemu and failing when run inside one of the container mechanisms used by salsaci or debci. Do you have some concrete issues in mind that prevent you from running autopkgtest on architecture X? In case your code does not care about full machine emulation or the kernel, or the bootloader, maybe all you want is a foreign architecture chroot where your code can run with qemu user mode emulation and then you skip all the quirks and bugs related to running full qemu machines? Thanks! cheers, josch
Attachment:
signature.asc
Description: signature