Package Details: libguestfs 1.38.2-1

Git Clone URL: https://aur.archlinux.org/libguestfs.git (read-only)
Package Base: libguestfs
Description: Access and modify virtual machine disk image
Upstream URL: http://libguestfs.org
Licenses: GPL2, LGPL2.1
Provides: guestfish=1.38.2
Submitter: thatch45
Maintainer: skalkoto
Last Packager: skalkoto
Votes: 77
Popularity: 4.838828
First Submitted: 2010-12-13 04:01
Last Updated: 2018-05-27 11:42

Latest Comments

ozz commented on 2018-06-17 02:35

Why aren't standard utilities like this part of the main Arch repositories? It's so weird and awkward.

Kalinda commented on 2018-04-26 15:06

@rwmjones Hey, hey, so here's my full on build log - https://andontie.net/stuff/libguestfs-build-log.txt

rwmjones commented on 2018-04-26 07:21

On the appliance, there is already support for pacman in supermin (https://github.com/libguestfs/supermin/blob/master/src/ph_pacman.ml). If you enable that then there's no need to download anything, the appliance will be built on the fly, just like how it works on every other distro.

About the errors seen by Kalinda: Looks like a problem with gnulib, but you'd need to pastebin the complete build log to find out exactly what went wrong.

Kalinda commented on 2018-04-25 22:25

Hello, I am unable to build this, I just keep getting errors like these - https://paste.ee/p/wcGpn

There's quite a few of them but it looks like they are all the same two errors. Any help appreciated, I may have missed installing something. Thnks!

CyberShadow commented on 2018-04-21 12:08

Sounds like the perfect case of moving it to its own package, then! E.g. libguestfs-appliance, with libguestfs depending on it.

Trying to do the package manager's job is going to cause a lot of subtle problems. For example, with the current method, any proxy configuration (or other download methods) that would have been used by pacman won't be visible to custom download scripts, and it's not possible to verify the integrity of files installed in this way using e.g. paccheck.

skalkoto commented on 2018-04-21 05:33

The appliance gets updated less frequent than the library itself. Only after a major library update you need to update the appliance. If the correct appliance is already downloaded by a previous installation, an upgrade will not download it again.

CyberShadow commented on 2018-04-11 19:09

Why is the "appliance" (http://libguestfs.org/download/binaries/appliance/appliance-${VERSION}.tar.xz) downloaded by a script ran from the .install file? Wouldn't doing it from the PKGBUILD (or as a separate package if it updates more frequently than the rest) be more appropriate?

I don't know if there's a packaging guideline against downloading things in .install files, but this seems pretty out there...

rwmjones commented on 2018-03-17 12:15

In Fedora we compile (part of) libguestfs twice in order to build both sets of bindings. Search for ‘python’ starting here:

https://src.fedoraproject.org/rpms/libguestfs/blob/master/f/libguestfs.spec#_847

One day soon we'll drop Python 2 and this problem will go away.

skalkoto commented on 2018-03-17 12:02

@sanerb: I don't think there is a way to compile libguestfs with having both python 2 and python 3 bindings enabled. If you change the _pythonver variable in the PKGBUILD script to 3, it will compile the library with python 3 support

sanerb commented on 2018-02-28 05:53

hey, it looks like you currently only distribute python2 bindings:

[bts@cylon ~]$ pacman -Ql libguestfs|grep python
libguestfs /usr/lib/python2.7/
libguestfs /usr/lib/python2.7/site-packages/
libguestfs /usr/lib/python2.7/site-packages/guestfs.py
libguestfs /usr/lib/python2.7/site-packages/libguestfsmod.so
libguestfs /usr/share/man/man3/guestfs-python.3.gz

can you please also include python 3 bindings?

you may or may not need this: https://www.mail-archive.com/libguestfs@redhat.com/msg13973.html

All comments