Package Details: xen-docs 4.19.1pre-1

Git Clone URL: https://aur.archlinux.org/xen.git (read-only, click to copy)
Package Base: xen
Description: Xen hypervisor documentation and man pages
Upstream URL: https://xenproject.org/
Keywords: hypervisor virtualization xen
Licenses: GPL2
Submitter: sergej
Maintainer: Refutationalist
Last Packager: Refutationalist
Votes: 185
Popularity: 0.47
First Submitted: 2009-11-09 11:22 (UTC)
Last Updated: 2024-09-20 00:31 (UTC)

Dependencies (35)

Required by (1)

Sources (7)

Pinned Comments

Refutationalist commented on 2024-12-06 01:37 (UTC)

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.

Latest Comments

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

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.

Refutationalist commented on 2023-04-23 22:26 (UTC)

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

Sven commented on 2023-04-23 21:49 (UTC)

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.

Sven commented on 2023-04-23 21:41 (UTC)

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.

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