Package Details: xen 4.20.0-2

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: 184
Popularity: 0.049349
First Submitted: 2009-11-09 11:22 (UTC)
Last Updated: 2025-03-13 08:19 (UTC)

Pinned Comments

Refutationalist commented on 2025-03-12 12:06 (UTC) (edited on 2025-03-13 08:23 (UTC) by Refutationalist)

We've moved to the newly-stable 4.20.0 branch. There are also other changes:

  • stubdom is fixed by disabling the vtmp and vtpmmgr components. This gets rid of a few source files and our remaining patches.
  • Debug files are only removed if the debug option is not set in makepkg.cfg (or the PKGBUILD itself)
  • pygrub has been removed
  • optdepends are adjusted for the upcoming xen-grub split package for the various Xen flavored builds.

If you're still using pygrub note that it is deprecated. The solution is to build PV grub instead, which used to be in AUR but is now missing. I am asking a couple questions on the mailing list, and I intend to put my current build of xen-grub (which supersedes xen-pvhgrub) on AUR as soon as possible. If you need to build it before that occurs, you can find it in my PKGBUILD repo.

EDIT: 4.20.0-2 adds support for the xen-edk2 package, which has a fixed UEFI for xen

Latest Comments

« First ‹ Previous 1 .. 8 9 10 11 12 13 14 15 16 17 18 .. 101 Next › Last »

Refutationalist commented on 2020-07-20 18:55 (UTC)

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.

Refutationalist commented on 2020-07-20 18:49 (UTC)

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.

Refutationalist commented on 2020-07-10 05:16 (UTC) (edited on 2020-07-10 05:17 (UTC) by Refutationalist)

@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.

eduncan911 commented on 2020-07-01 10:57 (UTC)

@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.

JohnTh commented on 2020-06-30 22:46 (UTC)

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.

Refutationalist commented on 2020-06-30 21:07 (UTC)

Thank you for your work, FFY00.

I'm currently out in the woods with limited internet. I'll be back sometime next week, at which point I'll clean up outstanding changes in my repo and push it to AUR. I didn't care about the docs package, but I can re-add that.

I'll also talk to the QEMU maintainers about adding the configure arg for Xen to QEMU, and seeing what they're doing upstream about GCC and python changes. I'll also likely push my PVH kernel to AUR.

Refutationalist commented on 2020-06-30 01:51 (UTC) (edited on 2020-06-30 20:22 (UTC) by Refutationalist)

@FFY00: The package I'm working on is very much based on your work and is intended as an interim solution while you are doing things properly. I tried to make that clear in my notes. If I have given any other impression, it is not intended and I apologize.

I had a personal itch to scratch and I shared my work. I wasn't figuring on much of anything beyond that, so the formatting changes didn't really matter to me very much. You're welcome to use what I've done or dismiss it entirely.

FFY00 commented on 2020-06-28 00:05 (UTC)

There were several things that blocked me from updating the package, you should be able to find the discussion below. If you think you are able to do it package the new version properly, please show me a PKGBUILD and I'll disown.

sl4mmy commented on 2020-06-22 15:13 (UTC)

@Refutationalist Unfortunately, it's difficult to diff your changes against this PKGBUILD because of all the formatting changes. Do you plan on rebasing your changes on top of this pkg, or do you consider your work to be a hard fork at this point?

Here is the minimal diff I came up with on top of this PKGBUILD to get 4.13.1 building with latest GCC (& drop the python2 dep): https://github.com/sl4mmy/docker-aur-xen/blob/master/aur-xen_PKGBUILD.patch. The two patches for GCC 10 compile fixes can be found here: https://github.com/sl4mmy/docker-aur-xen/blob/master/gcc-10-fixes.patch, and here: https://github.com/sl4mmy/docker-aur-xen/blob/master/gcc-10-ipxe-fixes.patch.

It would be great if we could get this pkg updated to 4.13.1, including all of your additional improvements (stubdom, rundir, firmware hooks, etc.).

Refutationalist commented on 2020-05-24 21:37 (UTC)

@ntegan: that's good to hear. I'll probably want to look at changing the GRUB scripts then to look for xen.gz instead of a versioned file.

My justification is that I use either syslinux or direct EFI boot, and having to change my settings on every revision is suboptimal. Also, since other kernels aren't versioned in the repos, it seemed a bit more Arch-like to me.

In the meantime, since I first posted I've made a couple of bugfixes. I moved ipxe out of _stubdom_sources as it's not for stubdom, set rundir, and then added a hook to extract firmware from intel-ucode so xen EFI can use it. I'm working on an AMD hook.

« First ‹ Previous 1 .. 8 9 10 11 12 13 14 15 16 17 18 .. 101 Next › Last »