Package Details: xen-stubdom 4.20.0-2

Git Clone URL: https://aur.archlinux.org/xen.git (read-only, click to copy)
Package Base: xen
Description: Xen hypervisor stubdom files
Upstream URL: https://xenproject.org/
Keywords: hypervisor virtualization xen
Licenses: GPL2
Submitter: sergej
Maintainer: Refutationalist
Last Packager: Refutationalist
Votes: 184
Popularity: 0.071098
First Submitted: 2009-11-09 11:22 (UTC)
Last Updated: 2025-03-13 08:19 (UTC)

Dependencies (42)

Required by (3)

Sources (13)

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 2 3 4 5 6 7 .. 101 Next › Last »

lapuglisi commented on 2023-07-03 14:04 (UTC)

For those of you facing the issue below:

xentoollog_stubs.c: In function ‘stub_xtl_ocaml_vmessage’: xentoollog_stubs.c:36:1: error: ‘caml_local_roots’ undeclared (first use in this function); did you mean ‘caml_local_roots_ptr’? 36 | caml_local_roots = caml__frame; \ | ^~~~~~~~~~~~~~~~
xentoollog_stubs.c:114:9: note: in expansion of macro ‘CAMLdone’ 114 | CAMLdone;
| ^~~~~~~~
xentoollog_stubs.c:36:1: note: each undeclared identifier is reported only once for each function it appears in 36 | caml_local_roots = caml__frame; \ | ^~~~~~~~~~~~~~~~
xentoollog_stubs.c:114:9: note: in expansion of macro ‘CAMLdone’ 114 | CAMLdone;
| ^~~~~~~~
xentoollog_stubs.c: In function ‘stub_xtl_ocaml_progress’: xentoollog_stubs.c:36:1: error: ‘caml_local_roots’ undeclared (first use in this function); did you mean ‘caml_local_roots_ptr’? 36 | caml_local_roots = caml__frame; \ | ^~~~~~~~~~~~~~~~ xentoollog_stubs.c:140:9: note: in expansion of macro ‘CAMLdone’ 140 | CAMLdone; | ^~~~~~~~

One workaround is to add the option '--disable-ocamltools' to the './configure' command line in the 'build' function inside PKGBUILD.

Finebread commented on 2023-06-19 18:00 (UTC)

I experience a same problem like manueljben posted here. During installation I get the same error. I tried older Xen version and I got the same error. I tried to change caml_local_roots to caml_local_roots_ptr, didn't work out.

manueljben commented on 2023-06-13 17:11 (UTC) (edited on 2023-06-13 17:11 (UTC) by manueljben)

new problem arised to me today... :-(

xentoollog_stubs.c: In function ‘stub_xtl_ocaml_vmessage’: xentoollog_stubs.c:36:1: error: ‘caml_local_roots’ undeclared (first use in this function); did you mean ‘caml_local_roots_ptr’? 36 | caml_local_roots = caml__frame; \ | ^~~~~~~~~~~~~~~~
xentoollog_stubs.c:114:9: note: in expansion of macro ‘CAMLdone’ 114 | CAMLdone;
| ^~~~~~~~
xentoollog_stubs.c:36:1: note: each undeclared identifier is reported only once for each function it appears in 36 | caml_local_roots = caml__frame; \ | ^~~~~~~~~~~~~~~~
xentoollog_stubs.c:114:9: note: in expansion of macro ‘CAMLdone’ 114 | CAMLdone;
| ^~~~~~~~
xentoollog_stubs.c: In function ‘stub_xtl_ocaml_progress’: xentoollog_stubs.c:36:1: error: ‘caml_local_roots’ undeclared (first use in this function); did you mean ‘caml_local_roots_ptr’? 36 | caml_local_roots = caml__frame; \ | ^~~~~~~~~~~~~~~~ xentoollog_stubs.c:140:9: note: in expansion of macro ‘CAMLdone’ 140 | CAMLdone; | ^~~~~~~~

Refutationalist commented on 2023-05-15 03:12 (UTC)

personal update: It's going to be a bit before I can really look at these changes as I've had hand surgery and typing is not recommended at the moment. Feel free to keep submitting patches here or PRs at my github and I'll update the package itself as soon as I can.

Serus commented on 2023-05-06 16:30 (UTC)

I observed the code and it seems to be a false positive in GCC. I wrote a little patch that silences the warning:

From a033f9c535e41140a3138edbb0d6a89be0e80564 Mon Sep 17 00:00:00 2001
From: Xen Arch <user@xen-arch>
Date: Sat, 6 May 2023 17:58:47 +0200
Subject: [PATCH] Silence false positive use after free warning

---
 tools/libs/guest/xg_offline_page.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/libs/guest/xg_offline_page.c b/tools/libs/guest/xg_offline_page.c
index ccd0299f0f..96f197a801 100644
--- a/tools/libs/guest/xg_offline_page.c
+++ b/tools/libs/guest/xg_offline_page.c
@@ -182,9 +182,11 @@ static int backup_ptes(xen_pfn_t table_mfn, int offset,
     if (backup->max == backup->cur)
     {
         void *orig = backup->entries;
+       // silence false positive warning
+       void *orig2 = orig;

         backup->entries = realloc(
-            orig, backup->max * 2 * sizeof(struct pte_backup_entry));
+            orig2, backup->max * 2 * sizeof(struct pte_backup_entry));

         if (backup->entries == NULL)
         {
--
2.40.1

Simply save it as a .patch file, and drop it in the same folder as the PKGBUILD. Run sha512sum on it and put the patch file in the _patches list and the sha512 sum in the _patch_sums list.

Sven commented on 2023-05-06 11:56 (UTC)

xen fails to build with gcc 13.1.1 with -Werror=use-after-free error. Can we disable -Werror? New gcc versions typically bring new warnings. I respect the decision by the xen devs to treat them as errors. It keeps the code base clean. But it's not really convenient for us users.

Refutationalist commented on 2023-04-24 00:14 (UTC) (edited on 2023-04-24 00:14 (UTC) by Refutationalist)

in short:

  • the guidance comes from the documentation with XSAs and correspondence. example: https://xenbits.xen.org/xsa/advisory-429.html

  • though by following the stable branch a lot of these patches already get included

  • this pkgbuild has buildtime options, which obviates reproducable builds. at some future date those will be gone

  • yay compatibility is not a concern of mine at the moment, and it's in "considered harmful" territory for me regarding servers

  • you can see what my future plans are at my repo, but in short i do plan on doing most of what you're asking: https://github.com/refutationalist/saur

sorry for the terse response, typing is a bit diffucult for me at the moment

Sven commented on 2023-04-23 23:45 (UTC)

@Refutationalist Can you provide a link to upstream's requested best practices?

I have checked the stable-4.17 branch. The release of 4.17.0 was 4 months ago. Since then, the branch has been updated periodically. In result, everytime I build this package, I will end up with a different commit/version of xen. Please understand that this comes to me as a surprise. On Gentoo, authors typically offered some sort to of *-git package that would always give you the latest version from git. I'm not quite sure if such packages exist in AUR. But please indicate in the name of the package, that it's not building a release but always the latest from a certain branch.

At some point, the version reported by pkgver() was 4.17.0. Currently, it is 4.17.1pre. pkgver() has reported this string for a while now and it will continue to do so until upstream changes it to 4.17.1rc or 4.17.1 (release). So it's basically impossible to tell which xen-*.pkg.tar.zst is newer or older. This seems like a nightmare for us users to me. I would like to persuade you to include the date and (optionally) even the git commit hash in the output of pkgver().

If you had a binary repo, you could only push out updates to users if the version number actually changes (actually it needs to increase!). So what pkgver() currently does is insufficient for the purpose of your binary repo and it's also a hassle for us users who use the AUR.

The current PKGBUILD is also incompatible with package managers like yay. Yay will only pick up an update if the pkgver variable in PKGBUILD changes. The pkgver() function is ignored in this context.

Also, some users may prefer repeatable builds. With the current PKGBUILD, it's not trivial to repeat a previous build. It's quite a hassle to find the commit id of a previously built binary package and to patch the PKGBUILD to repeat that build.

Sorry for that much criticism. I appreciate your contribution. I currently rely on your work for my Arch-based dom0.

« First ‹ Previous 1 2 3 4 5 6 7 .. 101 Next › Last »