Refactor lima and qemu #2
Conversation
Signed-off-by: Jan Dubois <[email protected]>
Signed-off-by: Jan Dubois <[email protected]>
Signed-off-by: Jan Dubois <[email protected]>
jandubois
force-pushed
the
refactor-lima-and-qemu
branch
from
b5afefc
to
dc8bb3c
Compare
The aarch64 version no longer collected the qemu libraries. That's why it was re-implemented by parsing the `otool -L` output. It eventually turned out that the Homebrew had switched to Lima 1.0.0, which uses `--vm-type vz` by default (when available). The FileMonitor version does not collect kvmvapic.bin and vgabios-virtio.bin. They may not be needed when the VM is run without a display, but it for now it seems safer to keep them in the tarball. The script has also been changed to re-analyze an existing filemonitor.log. This makes no difference on CI but helps debugging the script. Signed-off-by: Jan Dubois <[email protected]>
jandubois
force-pushed
the
refactor-lima-and-qemu
branch
from
dc8bb3c
to
886b81d
Compare
| run: | | ||
| version=$(git describe --match 'v[0-9]*' --dirty='.m' --always --tags) | ||
| echo "VERSION=${version#v}" >>"$GITHUB_OUTPUT" | ||
| - name: Uninstall all brew packages and clear cache |
There was a problem hiding this comment.
Would it be easier to just provide a different homebrew prefix? I'm wary of randomly uninstalling things that the rest of the stuff might need.
There was a problem hiding this comment.
I don't know, what is "the rest of the stuff"? This job just builds QEMU from source and then runs lima-and-qemu.pl. There is nothing else. And we explicitly install every other tool needed to do these.
I also don't think something like having multiple homebrew installations are going to work. Especially since we are running on a macOS version that homebrew really doesn't want to run on anymore, so each experiment takes hours.
Given that I've spent several days battling with homebrew about this, I'm kind of unwilling to spend extra effort on this unless there is an actual problem.
| run: | | ||
| set -o xtrace | ||
| brew tap-new rd/tap | ||
| cp qemu.rb "$(brew --repo rd/tap)/Formula/qemu.rb" |
There was a problem hiding this comment.
Would it make sense to checkout into the directory instead?
There was a problem hiding this comment.
I'm not sure I understand the question. This step is creating a new tap, that will be inside the homebrew-managed directory structure. Do you want to create a separate repo to store a tap on GitHub? That seems like overkill compared to copying a single file.
There was a problem hiding this comment.
We have a actions/checkout step, and here we copy the qemu.rb into the tap directory. I was wondering if calling actions/checkout directly into …/Formula would be useful.
There was a problem hiding this comment.
But then everything else from this repo would be inside the new tap too. And directory doesn't even exist yet. I don't know how this would be simpler; it feels more complicated, and having to call the lima-and-qemu.pl script like this looks just wrong to me:
perl "$(brew --repo rd/tap)/Formula/lima-and-qemu.pl"
I'm sorry, I must be missing something.
Signed-off-by: Jan Dubois <[email protected]>
Build qemu on macOS with an empty brew install, and then archive the cache directory to provide the sources used in the build.
Include the tag/version string in the artifact tarballs.
On Linux set
LD_LIBRARY_PATHforappdir-qemu.shto make sure we capture all the libsProvide an alternative
USE_OTOOLto collect files on macOS. That turned out not to be necessary, but let's keep it in case `filemonitor will at some point require disabling SIP or something like that.