To solve temporally I think you can edit the qemu.pod file and change the name Schütz to Schutz.
Search Criteria
Package Details: xen 4.19.1pre-1
Package Actions
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: | 185 |
Popularity: | 0.67 |
First Submitted: | 2009-11-09 11:22 (UTC) |
Last Updated: | 2024-09-20 00:31 (UTC) |
Dependencies (63)
- acpica
- bridge-utils
- glib2 (glib2-gitAUR, glib2-selinuxAUR, glib2-patched-thumbnailerAUR)
- gnutls (gnutls-gitAUR)
- inetutils (inetutils-gitAUR, busybox-coreutilsAUR)
- iproute2 (iproute2-gitAUR, busybox-coreutilsAUR, iproute2-selinuxAUR)
- lib32-glibc (lib32-glibc-gitAUR, lib32-glibc-linux4AUR, lib32-glibc-eacAUR, lib32-glibc-eac-binAUR, lib32-glibc-eac-rocoAUR)
- libaio (libaio-gitAUR)
- libjpeg-turbo (mozjpeg-gitAUR, libjpeg-turbo-gitAUR, mozjpegAUR)
- libpng (libpng-gitAUR, libpng-apngAUR)
- libseccomp (libseccomp-gitAUR)
- libuuid.so (util-linux-libs-selinuxAUR, util-linux-libs-aesAUR, lib32-util-linux, util-linux-libs)
- libx11 (libx11-gitAUR)
- lzo
- ncurses (ncurses-gitAUR)
- openssl (openssl-gitAUR, openssl-staticAUR)
- pciutils (pciutils-gitAUR)
- pixman (pixman-gitAUR)
- pkgconf (pkgconf-gitAUR)
- python (python37AUR, python311AUR, python310AUR)
- Show 43 more dependencies...
Required by (3)
Sources (7)
Latest Comments
« First ‹ Previous 1 .. 65 66 67 68 69 70 71 72 73 74 75 .. 101 Next › Last »
hugleo commented on 2013-05-28 23:54 (UTC)
tritron commented on 2013-05-28 23:32 (UTC)
Well looks like the latest upgrades perl 5.18 breaks xen I get this error.
pod2man --section=1 --center=" " --release=" " qemu.pod > qemu.1
qemu.pod around line 91: Non-ASCII character seen before =encoding in 'Schütz.'. Assuming UTF-8
POD document had syntax errors at /usr/bin/core_perl/pod2man line 71
kantras commented on 2013-05-28 18:27 (UTC)
Sorry, I've been offline a few days - once I get a chance, I'll retest on my lab machine.
3000 commented on 2013-05-28 17:36 (UTC)
@ Kantras:
is your solution still working for you?
thanks
3000 commented on 2013-05-25 13:56 (UTC)
I also tried xen-git, also not working (yet). Thanks also for the xen-users mailing list idea. I will post my Problem over there shortly.
I have to correct myself though regarding my last post: I said I was able to install xen only in legacy boot. Well to be more precise, I was able to boot INTO xen with legacy boot.
With UEFI boot, I was still able to successfully install xen, BUT once I tried to boot into Arch Xen, the system would constantly just reboot. That's my real Problem. And once I tried to apply Kantras solution (modifying binutils-multilib before installing xen), installation broke down. I know it's not arch related, I still thought it's worth mentioning. There is a decisive difference to my last post.
tritron commented on 2013-05-25 00:23 (UTC)
3000 try xen-git package users had been able to compile xen.efi and it is working
zootboy commented on 2013-05-24 23:20 (UTC)
@3000 I would suggest posting your problem in the xen-users mailing list. You're much more likely to get help there, as this isn't an Archlinux-specific problem. Just make sure to mention the fact that you're using Arch.
3000 commented on 2013-05-24 22:31 (UTC)
I am really sorry, I totally forgot to mention that I CAN actually build xen - but only with legacy boot. However it won't build with UEFI boot. I already tried the solution posted below by Kantras. He used a modified binutils-multilib. He posted his solution in late 2012. So I am not sure it's still relevant. I tried, but it doesn't work for me.
hugleo commented on 2013-05-23 21:35 (UTC)
Here I've compiled perfectly using yaourt.
You can try re generate the locales:
cat /etc/locale.conf
LANG="en_US.UTF8"
locale-gen
Generating locales...
en_US.UTF-8... done
en_US.ISO-8859-1... done
You can also try on a fresh arch "systemd" installation.
uname -a (64 bits)
Linux archlocal 3.9.3-1-ARCH #1 SMP PREEMPT Sun May 19 22:50:29 CEST 2013 x86_64 GNU/Linux
zootboy commented on 2013-05-23 21:31 (UTC)
@3000 That's the line. And no, unfortunately, I don't have any UEFI motherboards to test on. Though I find it strange that UEFI would make the difference on that line in particular, I won't rule it out as a possibility. You should definitely try removing that line, as trying can't hurt at this point.
Also, there's been some chat on the xen-users mailing list about UEFI stuff recently. Are you trying to compile on a 32-bit kernel?
Pinned Comments
Refutationalist commented on 2024-05-22 22:08 (UTC) (edited on 2024-05-23 00:07 (UTC) by Refutationalist)
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