Re: Any way to install packages+run autopkgtests on porterbox machines?
On Sun, 2024-03-03 at 10:20 -0800, Ross Vandegrift wrote: > Not exactly an answer, but an alternative - it's easy to get an ARM VM from > many cloud providers. For a buck or two, I've avoided hours of futzing with > the porterboxes. I've heard of providers with PPC, but haven't ever actually > used one. There is a list of gratis and paid hardware providers here: https://wiki.debian.org/Hardware/Wanted#Available_hardware -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Any way to install packages+run autopkgtests on porterbox machines?
On Fri, Mar 01, 2024 at 06:28:50PM +0530, Nilesh Patra wrote: > 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. Not exactly an answer, but an alternative - it's easy to get an ARM VM from many cloud providers. For a buck or two, I've avoided hours of futzing with the porterboxes. I've heard of providers with PPC, but haven't ever actually used one. Ross
Re: Any way to install packages+run autopkgtests on porterbox machines?
On Sun, 03 Mar 2024 at 22:52:26 +0530, Nilesh Patra wrote: > If I want to run tests with another package (say a test dependency) that I > fixed > locally on a particular arch (which is not amd64) -- how doI run autopkgtests > with > this combo on a porter machine? Unfortunately, the general answer is that you can't. If this makes it impossible for you to solve a bug, then you can't solve that bug without assistance from a user of that architecture. For specific classes of package, you might be able to work around this: for example if you've attempted to fix a bug in a C/C++ library, you might be able to convince the autopkgtest to pick up the patched library via LD_LIBRARY_PATH, or if you've attempted to fix a bug in a Python library, the same is true for PYTHONPATH. This will not be testing the package "as-installed", so it's far from perfect, but it's better than nothing. If we had porterboxes where it was possible to create a container environment as an unprivileged user (see https://salsa.debian.org/debian/grow-your-ideas/-/issues/40, which I'm sorry to say I have not had sufficient energy to drive beyond opening the initial suggestion) then that would be a 95% solution for this, but that would require the DSA team to be willing to allow that, which would increase security exposure to an extent that might well be considered to be unacceptable. I'm sorry to be bringing bad news without presenting an actionable solution. smcv
Re: Any way to install packages+run autopkgtests on porterbox machines?
On Sun, Mar 03, 2024 at 06:09:47PM +0100, Paul Gevers wrote: > On 01-03-2024 1:58 p.m., Nilesh Patra wrote: > > Have you found any way around these? > > https://salsa.debian.org/mbanck/dd-autopkgtest/ Thanks, I will use this for autopkgtests. This however also only partially solves the issue for me. If I want to run tests with another package (say a test dependency) that I fixed locally on a particular arch (which is not amd64) -- how doI run autopkgtests with this combo on a porter machine? Best, Nilesh signature.asc Description: PGP signature
Re: Any way to install packages+run autopkgtests on porterbox machines?
Hi, On 01-03-2024 1:58 p.m., Nilesh Patra wrote: Have you found any way around these? https://salsa.debian.org/mbanck/dd-autopkgtest/ Alternative, probably not the best solution, but until better ones are found (and as long it's not too much used): Antonio and I offer DD's access to testbeds with failed tests when contacted (preferably by signed e-mail). This is no wildcard access, we'll need to align on the time you want access. The advantage is that you run inside the setup that's used by ci.d.n on the arch you need. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Any way to install packages+run autopkgtests on porterbox machines?
On 3/1/24 18:08, Andrey Rahmatullin wrote: On Fri, Mar 01, 2024 at 07:15:16PM +0530, Nilesh Patra wrote: You can use local sbuild chroots for foreign architectures, both for building and, I assume, running autopkgtests. I know but that is not something I want. This invaidates the whole point of using porter machines. I though the whole point of using porter machines is being able to run at least something on architectures you don't have otherwise. Local chroots are superior to that, not inferior, when they are also available.. local schroots don't permit to run autopkgtest in the same env (Debian uses lsc), and I don't think we can reproduce distinct architectures inside lsc. (And when I follow the lsc doc given with autopkgtest, nothing work: no network inside containers). So Like Nilesh, I try to reproduce autopkgtest failures using modified build tests (and waste a lot of time to do that).
Re: Any way to install packages+run autopkgtests on porterbox machines?
Hi, Quoting David Bremner (2024-03-01 14:09:36) > Nilesh Patra 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 signature.asc Description: signature
Re: Any way to install packages+run autopkgtests on porterbox machines?
Le 2024-03-01 à 08 h 09, David Bremner a écrit : Nilesh Patra 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 have complained at length on IRC on the difficulties of running autopkgtests locally on non-amd64 architectures. 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. 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. While struggling with this issue I did find out that sbuild-qemu-create can be useful to build non-amd64 qemu images that are useable for autopkgtests, although that only supports a small subset of architectures. But I've thrown in the towel recently on jruby autopkgtests in part for this reason.
Re: Any way to install packages+run autopkgtests on porterbox machines?
On Fri, Mar 01, 2024 at 07:15:16PM +0530, Nilesh Patra wrote: > > You can use local sbuild chroots for foreign architectures, both for > > building and, I assume, running autopkgtests. > > I know but that is not something I want. This invaidates the whole point of > using > porter machines. I though the whole point of using porter machines is being able to run at least something on architectures you don't have otherwise. Local chroots are superior to that, not inferior, when they are also available.. -- WBR, wRAR signature.asc Description: PGP signature
Re: Any way to install packages+run autopkgtests on porterbox machines?
On Fri, Mar 01, 2024 at 06:03:16PM +0500, Andrey Rahmatullin wrote: > You can use local sbuild chroots for foreign architectures, both for > building and, I assume, running autopkgtests. I know but that is not something I want. This invaidates the whole point of using porter machines. Best, Nilesh signature.asc Description: PGP signature
Re: Any way to install packages+run autopkgtests on porterbox machines?
Nilesh Patra 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 have complained at length on IRC on the difficulties of running autopkgtests locally on non-amd64 architectures. 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. 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.
Re: Any way to install packages+run autopkgtests on porterbox machines?
On Fri, Mar 01, 2024 at 06:28:50PM +0530, Nilesh Patra wrote: > Hi, > > 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. > > Additionally, say, I have a package which FTBFS due to something broken in a > build dependency > on a particular architecture. > If I fixup the problem in the build-dependency, there is no way I could test > if the target > package really works on that arch since I do not see a way to install the > fixed builddep without > uploading it to the archive. > > Have you found any way around these? You can use local sbuild chroots for foreign architectures, both for building and, I assume, running autopkgtests. -- WBR, wRAR signature.asc Description: PGP signature
