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?

Best,
Nilesh

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQSglbZu4JAkvuai8HIqJ5BL1yQ+2gUCZeHRCgAKCRAqJ5BL1yQ+ 2uDPAP4gI0gqnXFkCV8i8SN1fzMjI5oYRUOg9Ypp2Qys7sZrKgD/RNHdM00ZmvNq GUpp6+NjmhU9aoEuTwWYDVFTXjw0nAk=
=piqP
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmXh0hQtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh 4wgP/1tMX+uoOo6lYD/VyvsdydOFXgZPWuJ8wj3eaaer3PeXHg9GTMty834XPXo6 d+Kx2rs3i3BqQIBZxEn/ae6IeRAf77dU7T5FvFV1x495e6NcdwOE0ZO7e6kdxFLi lG0fnYkQOzkV7MgToAKawCtjEEc/BKVC2YOlYpFDbNnxL50ttooEELV3xtW2GX0d eELyo4P0YUhF4UIabdEbVBk+DUIUWG/bSmC6wREN/3YZWQLIjY4zfWqGx8IGArnR Gnt9dwwfugB0ewpCQ+RJu5/GRU1Yp2dsng9dUoii7vJ7BT+yiN+6QM7HK468V76G 7/B2ehDCXNuXIzFrV9WoboWNmspMxuBvSBGjqEBPYLTEJjN/Xs2ZFNOj28qIfJzS JhRgx5a6TgMprcgcHlptoKg/tthAS/+/cOHXJ4T6S8BFXORlZhUA+L8H8yZiEie6 gEUyyFNaju08F/UXGigQ/D6kGrDkgRsvJl1qr5Yge4jyj3DMj5YH7oGpHRhBRVyr +WlYBjfd6nmfB6LIXa4E2bd9Gx49YjS9QzxcY6M6ESJBopouxMgSyl2WTTkzMTFu pb64VS7Aya0gB9xPn1SenXFHCk+1GGAYctMbx+KjtTuuJQEluN75h5OClKeYHavs KFS2Ck1zbUye1gtukiQZCGuPA/ZDWa+sT9/rIUViGKWUtpU3
=n7pP
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Nilesh Patra <[email protected]> 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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQSglbZu4JAkvuai8HIqJ5BL1yQ+2gUCZeHb7AAKCRAqJ5BL1yQ+ 2qqhAP4rGRWb6GvP8E8Zel/5HuPHq0S5TkHZYrkQsJOrhQXMcQEAiJlpqMC+ewL+ aAldTQRevVYYCaWTFfEU6Ya8KEFZcwo=
=DYWx
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmXh4VMtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh hnIP/RT+AH3SaGSLNsrmHLRgB/ZboYGChPQVMlAqOv+WcGB3GfkaeUWZoFMR44Kx rUEL+g7ntphJQYDVdVDwjYl3DtbfiNrHeNDcCXUdemLmpIxFW8rHebGyo5IS2AgM CQ+6J+XVRnVObUkatZ0khnPJ6DawoDft8ikYoMIXJVVH71ci1ahhLSjcJkU0GGCb +0E/uhCH5MW+fDNOzw1xlW35+G19ZqrZ+6iYk3qnT1Q+fva4s31TBcuGijPYubLB ndw2Oc9GvHBWRPqQ9L3vRYdM81IYFL4yap5WlJnd9m+eOkW07pNfU1nMW9jNESKp n8r+0lUIuYXpue5CAIEdY102Kxb789eiAVeCjiHcvGO10nvsZSjX6IRJQJsxz6PK WhBpOyCSWDLVPU8kqWcM4PCV8Peh3RM3VO7g1MRg5z6j9FIGmng+hE4uTS67raQh 0mEalvKtFQWzeQj/vQEn+DUwpQEFvt7pBjkUZK5CI5IGLki2qnIqkSjMj+F6aSFU LkqwJ0bo9/StoJpYo289dF1Fg/knR+2C0tIrEWXm+uU0lU6OKpqxhYSzf/Jh0Nqe nnfqMgvsF1WmKjSoRBpgd9Vv/OOMz+332n7z1XVzgkG8wqjdS5bsyR1lQzF/IkJC xAogIznEZTfaAWPKC7A3+qKD6HF3zLSEO3mx/UmuEUTVegs1
=Zjqq
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 2024-03-01 à 08 h 09, David Bremner a écrit :

Nilesh Patra <[email protected]> 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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Quoting David Bremner (2024-03-01 14:09:36)

Nilesh Patra <[email protected]> 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
--==============U19286211690964516=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmXiwQ8ACgkQ8sulx4+9 g+GYhxAAt5p2wIWygXKTrRN/tyUjsv5wfeknoM5MIKoj4bmzXpZKX2LR56IU0wri SFTK7frUpNLMQSSuoEHWpzgBU20tX7486VfyNwByw8QefvmxnuGXkMfdrC5Qn5Qf 8rBHu/qzTt4sP4xCi/k+QKJrwAtd3vs2B3x4ANCdGUlKERJtQyQ2yzvEHp0gL4D+ Z4uI5c7R7b/neYwxL36MDYOGjnGjS22qFuIXvhcC5KjsuHARyCwAqPWgLD7CAHc0 iz2KTSsxVf08cG4aUPNjlxHSh3BRSNqzkXT2Hj8I6XLbzh+UBev8NQ2UbAXh/Yha hq419h0UPrxtZc7eyTqSmTGrS8EcgjqZ5zP5Lu0f8SBpOOPgKdfDp6DC6QfTWkW9 66aX5qGOmr9bLONFqhH7yxrea52ej2G7MzaVpoPcjcTfOFO+e7dFiduIJPZLY4js B3M7lA/cRuQlao38qv6T1dTLCQ0IoD0ERfNMdYILmH8PmWTCC1yS4Sa2S+LPE5DN MbByL401ORFFGoUQul1U3x/DOnlDuw69Uve3+DfAzD/U+YaTLznL9uI5yVt1uCkh 1f1gfYl34nCpQJ6oxpoB+HapuoLhhQOV/gZ6SyD7vCR2FqbcqLKEJ0vUDGAolK6d AoWoAZxmRbkjngi8llrxs3beY1zHJ0+TY8FxHRvYSOd5Rm/kYWk=
=TR1o
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------dBy8iRMfGEX29jq4NgohYxLM
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

SGksDQoNCk9uIDAxLTAzLTIwMjQgMTo1OCBwLm0uLCBOaWxlc2ggUGF0cmEgd3JvdGU6DQo+ IEhhdmUgeW91IGZvdW5kIGFueSB3YXkgYXJvdW5kIHRoZXNlPw0KDQpodHRwczovL3NhbHNh LmRlYmlhbi5vcmcvbWJhbmNrL2RkLWF1dG9wa2d0ZXN0Lw0KDQpBbHRlcm5hdGl2ZSwgcHJv YmFibHkgbm90IHRoZSBiZXN0IHNvbHV0aW9uLCBidXQgdW50aWwgYmV0dGVyIG9uZXMgYXJl IA0KZm91bmQgKGFuZCBhcyBsb25nIGl0J3Mgbm90IHRvbyBtdWNoIHVzZWQpOiBBbnRvbmlv IGFuZCBJIG9mZmVyIEREJ3MgDQphY2Nlc3MgdG8gdGVzdGJlZHMgd2l0aCBmYWlsZWQgdGVz dHMgd2hlbiBjb250YWN0ZWQgKHByZWZlcmFibHkgYnkgDQpzaWduZWQgZS1tYWlsKS4gVGhp cyBpcyBubyB3aWxkY2FyZCBhY2Nlc3MsIHdlJ2xsIG5lZWQgdG8gYWxpZ24gb24gdGhlIA0K dGltZSB5b3Ugd2FudCBhY2Nlc3MuIFRoZSBhZHZhbnRhZ2UgaXMgdGhhdCB5b3UgcnVuIGlu c2lkZSB0aGUgc2V0dXAgDQp0aGF0J3MgdXNlZCBieSBjaS5kLm4gb24gdGhlIGFyY2ggeW91 IG5lZWQuDQoNClBhdWwNCg==

--------------dBy8iRMfGEX29jq4NgohYxLM--

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAmXkrtwFAwAAAAAACgkQnFyZ6wW9dQq9 NAf/W4JlBI6c5CbdWuxgHi6IWytwlqyZoLUzZYxGhtpH3BSn9ERXjTFT8fNsU603jauR/YEKVnNa ER3m/PWuX0lcBDmOFMmoN0FYMDVh2gBvltL0RbHs5xHlP3RRLM/tpDjjzmYkpu9npxB1ZR+Uc5tU zmpdFgWcL82IYZ43N8V4oDDzbAwWiIuXdJI2o4IiGm7sjm0fU4sSsveSkoanmVM/mRQKzkyaJVPe vnniQ19c60TERykKQRRNPdU7nktxIvJJse3PZ1DlPD1hBebbSMEtRRKKLCR0IP4Wurut1BLxVtSs 9QHES358Skvx488DFUl3kHKV2/RqcwiVqZIsY4o+jQ==
=orQ1
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQSglbZu4JAkvuai8HIqJ5BL1yQ+2gUCZeSx0QAKCRAqJ5BL1yQ+ 2iwiAQDvpvfjobEfZE2g7eS/P9lkYCYlTQ8M05u4OlU0y/5arwD/a1aUrnJgbT0u 43LIt3udpNB/yJJlTF6/X9eMMPEd+QA=
=2vpa
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)