| Git Clone URL: | https://aur.archlinux.org/xen.git (read-only, click to copy) |
|---|---|
| Package Base: | xen |
| Description: | Open-source type-1 or baremetal hypervisor |
| Upstream URL: | https://xenproject.org/ |
| Keywords: | hypervisor virtualization xen |
| Licenses: | GPL2 |
| Submitter: | sergej |
| Maintainer: | Refutationalist |
| Last Packager: | Refutationalist |
| Votes: | 185 |
| Popularity: | 0.67 |
| First Submitted: | 2009-11-09 11:22 (UTC) |
| Last Updated: | 2024-09-20 00:31 (UTC) |
@linuxninja - Yeah, my package is still requiring qemu-xen from my personal repo, something that I'll be fixing in the next update.
I'm also looking at 4.14.0, which is not compiling but looks to have some of the same problems as 4.13.1 did. I'll try to have something ASAP, depending on complexity and my workload.
I was able to build with the changes to the source that I noted, however, I am unable to start a HVM VM with the new build options in this PKGBUILD. I had to revert to the old PKGBUILD and go back to Xen 4.13.0.
source = https://src.fedoraproject.org/rpms/xen/raw/master/f/xen.gcc10.fixes.patch
https://src.fedoraproject.org/rpms/xen/raw/master/f/xen.ocaml.4.10.patch
Needs to be changed to
source = https://src.fedoraproject.org/rpms/xen/raw/f32/f/xen.gcc10.fixes.patch
https://src.fedoraproject.org/rpms/xen/raw/f32/f/xen.ocaml.4.10.patch
in the PKGBUILD. The f32 tag reflects the files the PKGBUILD has been using up to this point. The Master branch has moved on to Xen 4.14.0 and has removed the ocaml patch and the gcc10 patch is no longer the same file.
Ok, so it turns out I'm actually blind. Removing --with-system-qemu from the build function does the deed. Makes me think there should be an optdepends or depends on qemu if you're going that route so that it's slightly more obvious.
So how do I get a functional HVM with this release? (4.13.1-4) There's no /usr/lib/xen/bin/qemu-dm but I don't see anything obvious in the PKGBUILD as to why.
WANTED: Maintainer or co-maintainer.
I've written a lot of PKGBUILDs for my own purposes, but I'm not that conversant with AUR itself other than using it. I'm also going to be hip deep in work over the next few months and might miss stuff.
Okay, I've added the disable flag for qemut, and at least allowed the package to disable stubdom if people don't want it. I've also split out the docs package, as before. This package is currently at parity with what's in my git.
Next, I'd like to take a closer look at qemu before I willy-nilly push qemu-xen to AUR.
@JohnTh:
The minimal-components builds were never useful to me without modification, which is another reason why my personal repo is the way it is. But my build wasn't going to be on AUR, so I suppose I should revisit that. I invariably need stubdom, so I pulled out the optional check. Other stuff I can probably get rid of, qemut in particular.
I'm not familiar with what the community decisions were. I can review the comments, but that wasn't my initial aim and I took over the package as I seemed to have inadvertently caused a problem. Would it make more sense if you or someone else took over the package? I'm open to that.
Otherwise, I'm going to look into fixing what I have outstanding and updating the package sometime next week.
@JohnTh qemu requires the Xen headers to compile Xen support, so unless you can get this into an arch repository, it will be unlikely our qemu maintainers will want to build the Xen tools themselves.
I would prefer such headers/compilation to be a separate package, so to keep this one lean. Much like the kernel headers are available in an addition package.
It is much easier to support a minimal-components build:
Do we need?: - qemut (--disable-qemu-traditional) https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=configure;hb=staging - stubdom (--disable-stubdom) https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=configure;hb=staging - ipxe (only used with qemut rombios / with-system-ipxe exists, but only aur ipxe package) https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/firmware/Makefile;h=809a5fd0255e19b15abda6daf891ed1f5e63e9ad;hb=staging
qemu requires the Xen headers to compile Xen support, so unless you can get this into an arch repository, it will be unlikely our qemu maintainers will want to build the Xen tools themselves.
Most of these have been covered deeper in these comments: https://aur.archlinux.org/pkgbase/xen/?O=0&PP=100
My minimal Xen staging tee build seems to be compiling fine without any extra patches, but it is way too messy to use: https://gitlab.com/archlinux-packages-johnth/xen/-/blob/xen-git/PKGBUILD
Thanks FFY00 and Ref.
Pinned Comments
Refutationalist commented on 2024-05-22 22:08 (UTC) (edited on 2024-05-23 00:07 (UTC) by Refutationalist)
As of now (2024-22-05) Xen with stubdom doesn't build because of a problem in the imported code. Been this way for about two weeks. Anyone else seeing this behavior?
Also, there is a lot of work happening on Xen in my development repo, thanks to @Serus. Check it out at: https://github.com/refutationalist/saur