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/6427a74060dccf0baa34e33ddd7be2b680545594/vchan/Makefile.linux#L33)
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=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
