Arch Linux User Repository

Please Note: Per best-practices by upstream this package follows the git stable branch. Minor releases do not require a version bump and the PKGBUILD will provide the appropriate version number.

stubdom is still broken.

Your updated package on Github works out of the box. Maybe you could surround the new ninja makedepends with apostrophes, but it compiles without that change.

I tested with and without build_stubdom=true, it compiles and runs. Qemu is built and running as well.

The stubdoms are needed for virtual TPMs. I want to use them to store a LUKS key. But maybe someone else needs them to start Windows?

I do not have 4.16 in yet, but I suspect a lot of people by now know that 4.16 is compiling cleanly without extra patches. I just haven't had a chance to test it, or heard of anyone else testing it, so I haven't pushed my changes. I do have a simply updated package in my repo (https://github.com/refutationalist/saur) if you're interested in testing.

So, still out of date officially, but if I can get some confirmations that it works, I can push it here and leaving dealing with stubdom when I get back.

Other notes:

1) I got a request to leave stubdom in. Maybe I could make it part of the split package config? Looking into that, but probably not. The age of the extfiles needed for stubdom is starting to worry me and conflating with the "secure" aspects of stubdom. Part of what moved me to subdomless PVH.

2) I'm not able to recreate the qemu conflicts.

3) If building QEMU, we now need ninja.

4) I'm going to be playing with a Honeycomb LX2, so I'm hoping to have a version of xen that runs under alarm. Building for arm is really different, however.

On my system, the Xen 4.15.1-1 package fails to build. Any pointers ? GCC v11.1.0 ?

xentoollog_stubs.c:57: error: "Some_val" redefined [-Werror]
   57 | #define Some_val(v) Field(v,0)
      | 
In file included from /usr/lib/ocaml/caml/alloc.h:24,
                 from xentoollog_stubs.c:23:
/usr/lib/ocaml/caml/mlvalues.h:396: note: this is the location of the previous definition
  396 | #define Some_val(v) Field(v, 0)
      | 
cc1: all warnings being treated as errors
...
...
...
==> ERROR: A failure occurred in build().

I think it should conflict with qemu by default

error: failed to commit transaction (conflicting files)
xen: /usr/share/locale/bg/LC_MESSAGES/qemu.mo exists in filesystem (owned by qemu)
xen: /usr/share/locale/de_DE/LC_MESSAGES/qemu.mo exists in filesystem (owned by qemu)
xen: /usr/share/locale/fr_FR/LC_MESSAGES/qemu.mo exists in filesystem (owned by qemu)
xen: /usr/share/locale/hu/LC_MESSAGES/qemu.mo exists in filesystem (owned by qemu)
xen: /usr/share/locale/it/LC_MESSAGES/qemu.mo exists in filesystem (owned by qemu)
xen: /usr/share/locale/sv/LC_MESSAGES/qemu.mo exists in filesystem (owned by qemu)
xen: /usr/share/locale/tr/LC_MESSAGES/qemu.mo exists in filesystem (owned by qemu)
xen: /usr/share/locale/zh_CN/LC_MESSAGES/qemu.mo exists in filesystem (owned by qemu)
Errors occurred, no packages were upgraded.

Thank you for your commitment to this package. I never got the stubdom thing to work, but at some point I would like to try it again. So I would prefer if you keep the stubdom switch as it is implemented now.

Here's 4.15.1-1.

1) This one compiles cleanly on GCC11 et al., so there are currently no patches.

2) I'm well away from my usual haunts, so I'm only testing it on the Zen 2 machine I have with me, but it does boot and run HVM and PVH domUs.

3) We're expecting 4.16 around the end of the year, and so this is a reminder that when that's released, I'll be removing stubdom support as I was the only user.

4) I didn't know there was a Xen wiki page. I should update that at some point.

Hello! 4.15.0-3 is here. Here's an update:

1) The current GCC11 patch is updated for 4.15.0 and included here. It was in my github for a bit but I forgot to push it here. Whoops.

2) I've added the recent spate of XSA patches, but one had to be redone for our build environment. It is included.

3) mxca's fixes for EFI have been incorporated, but the directory is set to /boot by default, as I understand this is what is common.

4) On a personal note, my surgery went very well! I am still recovering, but things are looking good for me. Thank you for the well-wishes!

4.15.0-1 doesn't compile. Compilation stops with an error in line 729 of x86_emulate.c because of -Werror=stringop-overflow.

I assume that we see this error due to gcc 11. The command of mxca links to a patch for compiling with gcc 11.

Also, my best wishes go to Refutationalist. I hope the surgery goes well and you can return soon.

I came across this patch to get Xen building with GCC 11.

I also needed to make a few changes to support a system with split /efi and /boot (using XBOOTLDR). I ended up adding the make arguments BOOT_DIR=/boot EFI_DIR=/boot EFI_MOUNTPOINT=/efi. Technically that BOOT_DIR=/boot is redundant because it's the default, but I actually modified the package to set them as variables (e.g., _boot_dir=${boot_dir:-/boot}) and pass "${_common_make_flags[@]} to each make invocation.

EFI_DIR is where the xen.efi symlink farm gets installed along with the actual EFI image, so setting EFI_DIR=/boot looks weird but is the right thing to do on a SystemD bootctl-powered system using XBOOTLDR: the end result is that I don't need a hook to update the EFI system partition.

I also needed to refactor the symlink cleanup; specifically remove all the symlinks at the end after we've done both the multiboot and the EFI image relocations. Otherwise, if BOOT_DIR and EFI_DIR are the same thing you're gonna have a bad time.

I put my changes on github. Built it in a chroot with multilib-build, gonna go test it now.

Update: Works for me.

Thanks for your efforts. I wish you all the best with your surgery and a fast and painless recovery!