Arch Linux User Repository

pkgbuild was successful after changing _build_stubdom and _build_qemu from "build_qemu/stubdom:-true" to "build_qemu/stubdom:-false"

"ld: Error: unable to disambiguate: -no-pie (did you mean --no-pie ?)"

happens every build, regardless of the source. perhaps I am missing a dependency? it fails to build afterwards.

SDL2 has the least dependencies when display output is needed for (pv)hvm domUs. I run xen on two Laptops and gpu passthrough is not an option. I patch the PKGBUILD and the built-in qemu myself. I can continue to do that. So for my sake the SDL2 support can be removed.

I think spice support is automatically enabled when the spice and spice-protocol packages are installed before makepkg runs. This probably also applies to GTK, VTE and other configuration switches. This could be an alternative to a toggle in PKGBUILD, but should be documented somewhere.

Thanks for your efforts :)

Hello!

In my personal repo I have an updated version of 4.14.1 with security patches and the changes suggested in the last couple weeks. With the new hook, it will boot recent kernels, but both the most recent linux and linux-lts kernels will not start any virtual machines. I'm trying to narrow down where the problem happens still, but what I know is that 5.4.88 works, and 5.4.94 doesn't. If you want to help me track down the problem, my repo is at https://github.com/refutationalist/saur

And now some future stuff where I need some feedback:

Stubdom: I'm now transitioning to using the package without stubdom support. In the comments, I think I was the only person who needed it. If that continues to be the case, I will begin to phase out stubdom starting with the next Xen release.

SDL2: The number of dependencies goes up significantly if one uses the built-in QEMU support, which is the default as the package in extra does not have xen support in it. Since I run Xen almost entirely on headless machines, I'd like to remove SDL2 support. Unless someone says otherwise, I'll have QEMU configured to not use sdl2, otherwise I'll have to turn it into a toggle.

libvirt, qemu, and getting the package into the repos: I've talked to a couple of TUs who are interested in getting the package into the repos, but not much has actually happened on that score. I could try to become a TU myself, but I do have a lot on my plate and I don't know that I have the brain space to handle that. Would it make more sense for me to just abandon the package and hope a TU picks it up? Some direction from someone who knows the political ins and outs of Arch Linux would be very helpful.

just a nitpick: in optdepends edk2-ovmf is misspelled

I am using libvirt with Xen.

Unfortunately the [Community] package libvirt does not have Xen support, since it depends on Xen to build and Xen is in the AUR.

https://bugs.archlinux.org/task/64800

Is there any chance to get this package in [Community]?

@refutationalist I've been using a hook to deal with the zstd kernel issue until support is complete.

xen-kernel.hook:

[Trigger]
Operation = Install
Operation = Upgrade
Type = Package
Target = linux

[Action]
Description = Pull ELF kernel to /boot
Depends = linux-headers
When = PostTransaction
Exec = /usr/bin/strip /usr/src/linux/vmlinux -o /boot/vmlinux

@Refutationalist, regarding the zstd support, it seems support for Dom0 is in progress.

https://lists.xenproject.org/archives/html/xen-devel/2021-01/msg01060.html

I've tested this 4.14.1 on my older AMD box and my Xeon booting via EFI.

I'm in the middle of purging my need for the stubdom stuff, so I'm interested in hearing if people are using that at the moment. Also might have a co-maintainer shortly. Looking for input on how to handle zstd kernels.

4.14.1 has been out, and I'm working through it at the moment. Should hit my github repo in the next few days, and assuming it boots on my intel and AMD test systems, here shortly after.