Arch Linux User Repository

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

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.

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.

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.

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

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

@Sven: The package is built using upstream's requested best practices, particularly in regards to security. Since this way does not have the PKGBUILD strictly following point releases, it made sense to follow guidelines so we know what package we're building: https://wiki.archlinux.org/title/VCS_package_guidelines#The_pkgver()_function

That said, my ability to do package maintenance is limited at the moment. It'll be a few weeks before I can do more work on the package, at which point I'm planning on implementing some build automation so I can have more rigorous testing and-- hopefully-- a binary repo.

Sorry for posting so many messages. Please don't simply fetch the stable-4.17 branch. Please fetch a release tag, such as RELEASE-4.17.0.

Found that makepkg automatically updates the pkgver variable in PKGBUILD, if the pkgver() function exists. I would under the impression that this was not a package always fetching the latest from git. I expected this package to fetch the specified version (4.17.0) from git.

Why does running makepkg on this package modify the PKGBUILD file? I'm alarmed. That shouldn't happen. To be more specific, it changes the pkgver inside PKGBUILD from 4.17.0 to 4.17.1pre. I'd really like to build xen 4.17.0.

It seems like man-db is a missing build dep. Without man-db being installed, makepkg fails with some file not found error.