On 1/21/24 22:19, Daurnimator wrote:

There's not really any ongoing discussions.

For what it's worth, my personal motivation is to package qubes guest packages into the Arch [extra] repo, of which qubes-libvchan will depend on shared library from xen (https://github.com/QubesOS/qubes-core-vchan-xen/blob/6427a74060dccf0baa34e33...)

As an official package, it wouldn't have build options like your current AUR package. So I think you'd have to maintain an AUR xen-stubdom package separately.

This package is currently more about being a hypervisor rather than being a guest of one, and includes bootable kernels and infrastructure for such.   If this package is going to make it to official status with this functionality, the qemu package would have to be modified to support xen and likely a subpackage for it. The Xen codebase will build it's own copy of qemu unless told otherwise, and until a couple years ago that was what the PKGBUILD did.   I eventually had to spin off qemu into it's own package to avoid having to build an increasingly aging version of qemu with it's increasing number of compiler errors.  That package is here: https://aur.archlinux.org/packages/xen-qemu Without that functionality, it would be necessary to continue maintaining these packages in AUR.   In which case I would make effort to work with what exists in the repos. Previous maintainers have attempted to rid themselves of the stubdom functionality, but as of now it's the only consistent way to allow GPU pass-through.   I personally do not use this functionality, but I maintain it for those that do with an eye towards deprecating it as soon as newer PVH infrastructure is in place.   That should be very soon. For completeness, there's also the xen-pvhgrub package which is a copy of GRUB that runs under PVH domUs, allowing us to boot using Arch's standard kernel packages in that context.

Are you able to share why OCaml was disabled in your AUR package recently? (https://aur.archlinux.org/cgit/aur.git/commit/PKGBUILD?h=xen&id=e9890b16a5414cb48c4946d0a84193019a007a34)

Sure! The immediate cause was that the ocaml bindings were not building properly.  It was easier to remove them than try to repair them, especially as I have zero knowledge of ocaml.  There is some nuance to that, however: - The OCaml bindings are generally not well maintained upstream, afaik - The serially previous maintainers were working towards a minimum viable build, which I've tried to respect as much as I can - The flag to disable OCaml support was already in the ./configure stanza, but that flag had since been renamed - Apparently, no one was using it. I hope that helps explain things! -Sam