Summary: | app-emulation/qemu-guest-agent arm64 keyword | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Gentoo Linux | Reporter: | Forza <forza> | ||||||||
Component: | Keywording | Assignee: | John Helmert III <ajak> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | normal | CC: | forza, ladar, matoro_gentoo, sam, tamiko, virtualization | ||||||||
Priority: | Normal | Keywords: | CC-ARCHES, PullRequest | ||||||||
Version: | unspecified | Flags: | nattka:
sanity-check+
|
||||||||
Hardware: | ARM64 | ||||||||||
OS: | Linux | ||||||||||
See Also: | https://github.com/gentoo/gentoo/pull/34876 | ||||||||||
Whiteboard: | |||||||||||
Package list: |
app-emulation/qemu-guest-agent arm64
|
Runtime testing required: | --- | ||||||||
Attachments: |
|
Description
Forza
2023-11-09 11:22:23 UTC
Created attachment 876022 [details]
build.log
Seems to need some sort of qemu executable available?
Matoro, if you read your build log carefully, you'll see the guest agent compiled successfully, but failed during the unit test phase. It makes sense that would fail w/o the emulator available. The unit tests can't/won't run without the QEMU system emulator aka (qemu-system-aarch64/qemu-system-arm) being available. The guest agent itself appears to build/install just fine without the emulator using the command: env ACCEPT_KEYWORDS="*" emerge --ask=n --autounmask-write=y --autounmask-continue=y app-emulation/qemu-guest-agent Of course that command doesn't run the unit tests. Please add me to the list of people who would like to see this package enabled/available by default on ARM32/ARM64. I currently maintain Gentoo Vagrant base box images for X86/AMD64, and recently acquired an ARM build server. Which means I'm also going to start building ARM64 images (at least for the QEMU/libvirt providers), and would like to pre-install the guest agent in those box images. (In reply to Ladar Levison from comment #2) > Matoro, if you read your build log carefully, you'll see the guest agent > compiled successfully, but failed during the unit test phase. It makes sense > that would fail w/o the emulator available. The unit tests can't/won't run > without the QEMU system emulator aka (qemu-system-aarch64/qemu-system-arm) > being available. The guest agent itself appears to build/install just fine > without the emulator using the command: > > env ACCEPT_KEYWORDS="*" emerge --ask=n --autounmask-write=y > --autounmask-continue=y app-emulation/qemu-guest-agent > > Of course that command doesn't run the unit tests. > > Please add me to the list of people who would like to see this package > enabled/available by default on ARM32/ARM64. > > I currently maintain Gentoo Vagrant base box images for X86/AMD64, and > recently acquired an ARM build server. Which means I'm also going to start > building ARM64 images (at least for the QEMU/libvirt providers), and would > like to pre-install the guest agent in those box images. Hi Ladar, yes thank you for your work on robox, I've even contributed to the Gentoo support there. The issue is that we require a passing test suite in order to mark a package as working, as it's what allows us to identify regressions and really say that a package is "working" rather than just "builds". I've been thinking about how to go about fixing this. We're kind of stuck since the test suite really expects the corresponding qemu binaries to be present in the build tree, and it needs to be the relevant ones for the current arch. It's possible the correct solution is to merge into a USE-flag of app-emulation/qemu. Let me raise this as a discussion to the maintainers. Hi Matoro, I don't know the Gentoo packaging system well enough, so I didn't mention this above, but is possible to stipulate additional dependencies that are only required for testing? What makes things a little unusual in this instance is the guest agent source tarball already contains the code for the emulator/system binaries. They just aren't being compiled. Is it possible, alternatively, to adjust the configure options to build the emulator when your also running the tests? Or re-run configure and enable the emulator when starting the test step? One possible issue, which I don't know off-hand, is if it's possible to build the emulator just for testing, but not install it. I know it's possible to build the bundled firmware/ROMs for test purposes, but never looked for something like that related to the emulator binaries. How does the X86/AND64 version of the guest agent package handle this issue? I imagine it would run into the same problem. P.S. In the process of releasing the first A64 Gentoo box. Feel free to check it out and provide any relevant feedback. (In reply to Ladar Levison from comment #4) > Hi Matoro, I don't know the Gentoo packaging system well enough, so I didn't > mention this above, but is possible to stipulate additional dependencies > that are only required for testing? Yes of course, but as you mention below it specifically needs emulator binaries in the source tree, not just on the system. > What makes things a little unusual in this instance is the guest agent > source tarball already contains the code for the emulator/system binaries. > They just aren't being compiled. > > Is it possible, alternatively, to adjust the configure options to build the > emulator when your also running the tests? Or re-run configure and enable > the emulator when starting the test step? > > One possible issue, which I don't know off-hand, is if it's possible to > build the emulator just for testing, but not install it. I know it's > possible to build the bundled firmware/ROMs for test purposes, but never > looked for something like that related to the emulator binaries. The former approach is one possible option, but I do not know off the top of my head how to have it build those emulators and then not install them (short of deleting the binaries post-test, but there might be additional misc files that it builds when those options are flipped on) > How does the X86/AND64 version of the guest agent package handle this issue? > I imagine it would run into the same problem. It doesn't even though it's supposed to. The fact that the maintainers did not check it is a mistake, but it needs to be corrected for all arches before we can mark it as keyworded. > P.S. In the process of releasing the first A64 Gentoo box. Feel free to > check it out and provide any relevant feedback. (In reply to matoro from comment #5) > (In reply to Ladar Levison from comment #4) > > Hi Matoro, I don't know the Gentoo packaging system well enough, so I didn't > > mention this above, but is possible to stipulate additional dependencies > > that are only required for testing? > > Yes of course, but as you mention below it specifically needs emulator > binaries in the source tree, not just on the system. > > > What makes things a little unusual in this instance is the guest agent > > source tarball already contains the code for the emulator/system binaries. > > They just aren't being compiled. > > > > Is it possible, alternatively, to adjust the configure options to build the > > emulator when your also running the tests? Or re-run configure and enable > > the emulator when starting the test step? > > > > One possible issue, which I don't know off-hand, is if it's possible to > > build the emulator just for testing, but not install it. I know it's > > possible to build the bundled firmware/ROMs for test purposes, but never > > looked for something like that related to the emulator binaries. > > The former approach is one possible option, but I do not know off the top of > my head how to have it build those emulators and then not install them > (short of deleting the binaries post-test, but there might be additional > misc files that it builds when those options are flipped on) Couldva solution be to add a "test" USE-flag. When enabled, it builds full qemu sources with --enable-guest-agent, runs its tests, and if ok, can continue with rebuilding without the tests in a second run? > > > How does the X86/AND64 version of the guest agent package handle this issue? > > I imagine it would run into the same problem. > > It doesn't even though it's supposed to. The fact that the maintainers did > not check it is a mistake, but it needs to be corrected for all arches > before we can mark it as keyworded. > > > P.S. In the process of releasing the first A64 Gentoo box. Feel free to > > check it out and provide any relevant feedback. Another option, can we rely on app-emulation/qemu tests on the arch, and assume that the guest-agent will be ok? We could include something like ?test (--enable-guest-agent). Created attachment 882690 [details]
ebuild qemu-8.2.0.ebuild test log
I enabled "--enable-guest-agent" in qemu-8.2.0.ebuild and ran "ebuild qemu-8.2.0.ebuild test" on my x86 box (the aarch64 vm is very slow so it'll take a while before it finishes).
# Start of qga tests
ok 1 /qga/sync-delimited
ok 2 /qga/sync
ok 3 /qga/ping
ok 4 /qga/info
ok 5 /qga/network-get-interfaces
ok 6 /qga/get-vcpus
ok 7 /qga/get-fsinfo
ok 8 /qga/get-memory-block-info
ok 9 /qga/get-memory-blocks
ok 10 /qga/file-ops
ok 11 /qga/file-write-read
ok 12 /qga/get-time
ok 13 /qga/id
ok 14 /qga/invalid-oob
ok 15 /qga/invalid-cmd
ok 16 /qga/invalid-args
ok 17 /qga/fsfreeze-status
ok 18 /qga/blockedrpcs
# slow test /qga/blockedrpcs executed in 1,08 secs
ok 19 /qga/allowedrpcs
# slow test /qga/allowedrpcs executed in 1,00 secs
ok 20 /qga/config
ok 21 /qga/guest-exec
ok 22 /qga/guest-exec-separated
ok 23 /qga/guest-exec-merged
ok 24 /qga/guest-exec-invalid
ok 25 /qga/guest-get-osinfo
# slow test /qga/guest-get-osinfo executed in 1,00 secs
ok 26 /qga/guest-get-host-name
ok 27 /qga/guest-get-timezone
ok 28 /qga/guest-get-users
# End of qga tests
Created attachment 882695 [details]
aarch64 testlog of qemu-8.2.0.ebuild
Finished the ebuild test on the aarch64
# Start of qga tests
ok 1 /qga/sync-delimited
ok 2 /qga/sync
ok 3 /qga/ping
ok 4 /qga/info
ok 5 /qga/network-get-interfaces
ok 6 /qga/get-vcpus
ok 7 /qga/get-fsinfo
ok 8 /qga/get-memory-block-info
ok 9 /qga/get-memory-blocks
# slow test /qga/get-memory-blocks executed in 0.67 secs
ok 10 /qga/file-ops
ok 11 /qga/file-write-read
ok 12 /qga/get-time
ok 13 /qga/id
ok 14 /qga/invalid-oob
ok 15 /qga/invalid-cmd
ok 16 /qga/invalid-args
ok 17 /qga/fsfreeze-status
ok 18 /qga/blockedrpcs
# slow test /qga/blockedrpcs executed in 1.22 secs
ok 19 /qga/allowedrpcs
# slow test /qga/allowedrpcs executed in 1.18 secs
ok 20 /qga/config
ok 21 /qga/guest-exec
ok 22 /qga/guest-exec-separated
ok 23 /qga/guest-exec-merged
ok 24 /qga/guest-exec-invalid
ok 25 /qga/guest-get-osinfo
# slow test /qga/guest-get-osinfo executed in 1.20 secs
ok 26 /qga/guest-get-host-name
ok 27 /qga/guest-get-timezone
ok 28 /qga/guest-get-users
# End of qga tests
gentoo-aarch64 # qemu-ga --version
QEMU Guest Agent 8.2.0
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=99decf1e1533778a58f3c9bc7898c58526e7b780 commit 99decf1e1533778a58f3c9bc7898c58526e7b780 Author: Matoro Mahri <matoro_gentoo@matoro.tk> AuthorDate: 2024-01-18 06:39:01 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-02-02 03:54:45 +0000 app-emulation/qemu-guest-agent: add 8.2.0, limit test suite As noted, the only relevant test for the guest agent is test-qga, which is part of the qobject test suite, so limit to just this test suite. Bug: https://bugs.gentoo.org/917080 Signed-off-by: Matoro Mahri <matoro_gentoo@matoro.tk> Closes: https://github.com/gentoo/gentoo/pull/34876 Signed-off-by: Sam James <sam@gentoo.org> app-emulation/qemu-guest-agent/Manifest | 1 + .../qemu-guest-agent/qemu-guest-agent-8.2.0.ebuild | 88 ++++++++++++++++++++++ 2 files changed, 89 insertions(+) arm64 done all arches done |