Package Details: libguestfs 1.32.3-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.32.3
Submitter: thatch45
Maintainer: skalkoto
Last Packager: skalkoto
Votes: 47
Popularity: 2.415140
First Submitted: 2010-12-13 04:01
Last Updated: 2016-03-17 15:51

Dependencies (28)

Sources (2)

Latest Comments

mkingston commented on 2016-04-08 17:47

Perl bindings require Module::Build.
virt-win-reg requires Perl bindings (as far as I can tell).
Module::Build is in extra/perl-module-build.

Perhaps perl-module-build should be added as a dependency?

skalkoto commented on 2016-03-17 15:54

1.32.3-1

* New upstream version

skalkoto commented on 2016-03-08 10:41

yes, as axil42 already mentioned:

https://wiki.archlinux.org/index.php/Arch_User_Repository#Getting_started

axil42 commented on 2016-03-08 10:15

@m3thodic

These are included in the base-devel group-package which you need to install.

m3thodic commented on 2016-03-03 23:23

Requires bison and flex to build.

Thanks.

Siosm commented on 2016-02-18 18:44

@rwmjones: It is. This is a commonly reported non-issue that happens if Perl isn't installed when running the makepkg --syncdeps call to build a package. The Perl package will be installed, but the current shell session won't have sourced /etc/profile.d/perlbin.sh thus the Perl PATH won't be in the current shell PATH. Opening a new shell simply solves the issue.

rwmjones commented on 2016-02-18 09:45

Strange. Why isn't pod2text on the path, for example in /usr/bin? This appears to be a bug in the Perl package.

andreas_baumann commented on 2016-02-18 07:33

/bin/sh: pod2text: command not found
Fatal error: exception Failure("pod2text: process exited with non-zero status (127)")
Makefile:1796: recipe for target 'stamp-generator' failed

export PATH=/usr/bin/core_perl/:${PATH}

before configure needed

tomx3 commented on 2016-02-08 19:30

Version 1.32.2 is out since 2016-01-29.

mickours commented on 2016-02-03 19:20

Thanks javum! It solves the problem for me too :)

javum commented on 2016-02-02 16:13

Removing hardening-wrapper package solves my issue
https://bbs.archlinux.org/viewtopic.php?pid=1496413#p1496413

javum commented on 2016-02-02 13:56

I have the same error as mickours

skalkoto commented on 2016-01-26 09:45

It compiles just fine here

mickours commented on 2016-01-25 08:42

The build fails for me with this error:

Making all in ocaml/examples
make[2]: Entering directory '/tmp/yaourt-tmp-mercierm/aur-libguestfs/src/libguestfs-1.32.1/ocaml/examples'
ocamlfind ocamlopt -cclib -L../../src/.libs -package unix -linkpkg \
-warn-error A -I .. mlguestfs.cmxa create_disk.ml -o create_disk
/usr/bin/ld: /usr/lib/ocaml/libasmrun.a(startup.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/lib/ocaml/libasmrun.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
File "caml_startup", line 1:
Error: Error during linking
Makefile:1788: recipe for target 'create_disk' failed
make[2]: *** [create_disk] Error 2
make[2]: Leaving directory '/tmp/yaourt-tmp-mercierm/aur-libguestfs/src/libguestfs-1.32.1/ocaml/examples'
Makefile:1850: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/tmp/yaourt-tmp-mercierm/aur-libguestfs/src/libguestfs-1.32.1'
Makefile:1761: recipe for target 'all' failed
make: *** [all] Error 2

skalkoto commented on 2016-01-23 15:26

1.32.1-1

* New upstream version

skalkoto commented on 2015-11-30 09:57

1.30.4-1

* New upstream version

rwmjones commented on 2015-10-27 08:36

There should be a set of OCaml header files including <caml/config.h> located either in $libdir/ocaml/caml or /usr/include/caml. For some reason that wasn't installed or the libguestfs compile can't find it.

vmaffione commented on 2015-10-23 09:44

@rwmjones, I did what you suggested and I was able to go on.
However, I bumped into another problem, it cannot find ocaml headers.

make[2]: Entering directory '/home/vmaffione/git/libguestfs2/src/libguestfs-1.30.3/ocaml'
CC libguestfsocaml_a-guestfs-c.o
cc1: warning: -I../ocaml: No such file or directory [-Wmissing-include-dirs]
guestfs-c.c:28:25: fatal error: caml/config.h: No such file or directory
compilation terminated.
Makefile:1695: recipe for target 'libguestfsocaml_a-guestfs-c.o' failed
make[2]: *** [libguestfsocaml_a-guestfs-c.o] Error 1
make[2]: Leaving directory '/home/vmaffione/git/libguestfs2/src/libguestfs-1.30.3/ocaml'
Makefile:1923: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/vmaffione/git/libguestfs2/src/libguestfs-1.30.3'
Makefile:1795: recipe for target 'all' failed
make: *** [all] Error 2
==> ERROR: A failure occurred in build().
Aborting...

ocaml headers are correctly installed on my system, but it seems that it's looking for in-source headers.

rwmjones commented on 2015-10-13 07:53

> /usr/bin/ld: /usr/lib/ocaml/libasmrun.a(startup.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC

I don't have this problem. However with recent OCaml (>= 4.02.2), there should be a libasmrun_pic.a variant of this library, and you can link to it by adding:

-runtime-variant _pic

to the ocamlopt command line (how exactly to do that is left as an exercise for the reader). See also: http://caml.inria.fr/mantis/view.php?id=6693

noirbizarre commented on 2015-10-12 11:26

Didn't solve it but thanks.
I find this issue to be very close: https://bugs.archlinux.org/task/42748

skalkoto commented on 2015-10-11 06:50

@noirbizarre I've updated the package to version 1.30.3. You may try this one, but I've never seen your compilation error before. Is your system up-to-date?

skalkoto commented on 2015-10-11 06:47

1.30.3-1

* New upstream version

noirbizarre commented on 2015-09-26 11:45

Hi !

I can't manage to install the latest release, it fails with:

/usr/bin/ld: /usr/lib/ocaml/libasmrun.a(startup.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/lib/ocaml/libasmrun.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
File "caml_startup", line 1:
Error: Error during linking
Makefile:2094: recipe for target 't/guestfs_010_load.opt' failed
make[2]: *** [t/guestfs_010_load.opt] Error 2
make[2]: Leaving directory '/tmp/yaourt-tmp-noirbizarre/aur-libguestfs/src/libguestfs-1.30.1/ocaml'
Makefile:1921: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/tmp/yaourt-tmp-noirbizarre/aur-libguestfs/src/libguestfs-1.30.1'
Makefile:1795 : la recette pour la cible « all » a échouée
make: *** [all] Erreur 2

skalkoto commented on 2015-09-04 15:38

1.30.1-1

* New upstream version
* New binary appliance for 1.30.1 (thank you Richard!)

rwmjones commented on 2015-09-04 14:57

Should be available now.

skalkoto commented on 2015-09-04 14:19

@rwmjones Wouldn't it be better if you uploaded a new binary appliance for 1.30.1? As far as I see the commits that reduce the size of the binary appliance are cherry picked to the stable-1.30 branch.

rwmjones commented on 2015-09-01 05:29

> I added back a copy of hivex in AUR; but, I can't seem to get it
> to build without adding --disable-ocaml to ./configure and remeoving
> the ocaml dependencies...

Please email the full build errors/log to libguestfs@redhat.com.

bidulock commented on 2015-08-15 21:38

I added back a copy of hivex in AUR; but, I can't seem to get it to build without adding --disable-ocaml to ./configure and remeoving the ocaml dependencies...

swiftgeek commented on 2015-08-10 23:25

or more like http://pkgbuild.com/git/aur-mirror.git//tree/hivex

skalkoto commented on 2015-08-10 14:07

@spazmochad: If you are in a hurry, take a look at those:
https://github.com/axilleas/okeanos-archlinux/blob/master/hivex/PKGBUILD
https://rwmj.wordpress.com/2010/09/14/arch-linux-pkgbuild-for-hivex/
https://github.com/zepto/pkgbuilds/blob/master/aur/hivex/PKGBUILD

skalkoto commented on 2015-08-10 13:58

oh boy! It's gone. The maintainer was a user with username patryk. I guess he hasn't ported it to AUR 4 and the package is gone. I'll try to communicate with him to give me the old PKGBUILD to recreate it. If this does not work out, I'll create it from scratch within the next days.

spazmochad commented on 2015-08-10 13:20

Guys, what's the easiest way of getting hivex?

skalkoto commented on 2015-07-24 10:03

1.30.0-1

* New upstream version

The binary appliance for version 1.30.0 is quit big. From what I've seen, there are already pushed patches upstream to fix this. I assume libguestfs 1.30.1 will come with a new shorter binary appliance.

skalkoto commented on 2015-07-23 14:41

I was thinking of creating a new libguestfs-git package when I have some time to make use of the supermin appliance. A package that gets build using the latest source can be made workable again quite fast when an archlinux package used by libguestfs gets renamed.

rwmjones commented on 2015-07-23 13:02

It's uploading now, should be ready in a few minutes. For some reason the appliance has grown quite a lot (95MB in 1.28 -> 213MB in 1.30). I will take a look at why this has happened. (It doesn't really affect Fedora users since we only download the supermin appliance.)

rwmjones commented on 2015-07-23 12:31

Ah ha, thanks for reminding me :-) Indeed I should, and I will today.

skalkoto commented on 2015-07-23 12:16

@rwmjones:
Richard, you haven't uploaded a binary appliance for version 1.30.0 to http://libguestfs.org/download/binaries/appliance/

Are you planning to do it?

rwmjones commented on 2015-07-21 16:47

FYI 1.30.0 was released upstream today. The upstream release notes are here: https://www.redhat.com/archives/libguestfs/2015-July/msg00126.html

swiftgeek commented on 2015-06-28 19:48

bidulock: 1. AUR doesn't work this way
2. Care about planet and wasted cpu cycles, do not force people to recompile package AGAIN or edit pacman db manually / using changeling (available on aur)
3. The proper way™ of action on perl version change:
https://lists.archlinux.org/pipermail/arch-dev-public/2015-June/027236.html

bidulock commented on 2015-06-28 12:49

Please bump to 1.28.10-2 to trigger recompile against perl 5.22.

skalkoto commented on 2015-05-09 15:37

1.28.10-1

* New upstream version

jamesan commented on 2015-05-07 21:17

The current upstream stable release is 1.28.10, published on May 6, 2015:
http://libguestfs.org/download/1.28-stable/libguestfs-1.28.10.tar.gz
http://libguestfs.org/download/1.28-stable/libguestfs-1.28.10.tar.gz.sig

Release notes: http://libguestfs.org/guestfs-release-notes.1.html#release-notes-for-libguestfs-1.28

skalkoto commented on 2015-04-10 20:52

1.28.7-1

* New upstream version

skalkoto commented on 2015-02-08 13:42

1.28.6-1

* New upstream version

rwmjones commented on 2015-01-29 16:03

Three of these are obsolete. We keep them upstream for backwards compatibility for any scripts that people might have:

virt-list-filesystems
virt-list-partitions --> replaced by virt-filesystems (written in C)
virt-tar --> replaced by virt-tar-in/virt-tar-out (shell scripts)

However virt-win-reg is *not* obsolete, and jamesan is correct in saying that it requires perl's Locale::TextDomain library.

jamesan commented on 2015-01-29 15:52

The make dependency perl-libintl-perl is a proper dependency as well for at least these 4 libguestfs executables:
virt-list-filesystems
virt-list-partitions
virt-tar
virt-win-reg

skalkoto commented on 2015-01-11 10:55

1.28.5-1

* New upstream version

Lekensteyn commented on 2014-12-18 12:57

@N3rdle, I built libguestfs in a clean root with the testing repo enabled and had no issues. Here are the package versions: http://fpaste.org/160918/41890743/

Siosm commented on 2014-12-18 12:02

@N3rdle: Build is OK for me. Please try building in a clean chroot/container.

rwmjones commented on 2014-12-18 08:37

What version of gcc, what commands/options/configure are you actually trying, and what errors are you seeing?

N3rdle commented on 2014-12-18 06:40

Has anyone else attempted to build this now that link time optimizations are the default in gcc? I believe that with the internally used static libraries being created along the way in managing this amount of code, all the library consuming tools aren't being told how to use the proper lto plug-ins (ld, etc)... It breaks pretty spectacularly (with errors that tons of functions that are being linked via the static libraries are simply not found). I tried adding "-Wl,-plugin path-to-plugin" to the linking options and gcc/ld just crashed while linking.

I wish I understood the build mechanics a bit better, or I'd just fix this. What I had to do to get it to link was simply criminal. ;)

skalkoto commented on 2014-11-13 16:38

1.28.2-1

* New upstream version

Siosm commented on 2014-11-13 16:03

@Nowaker: builds fine here. Maybe you forgot to logout & log back in after installing perl?

rwmjones commented on 2014-11-13 15:51

Do you know which version of Perl? Works for me with perl 5.18.4.

Also the error message is bogus:

perl Makefile.PL INSTALLDIRS=site PREFIX=/usr
Only one of PREFIX or INSTALL_BASE can be given. Not both.

since we're obviously not passing INSTALL_BASE ...

Nowaker commented on 2014-11-13 15:40

[ . != . ] && cp -rsu /tmp/yaourt-tmp-nowaker/aur-libguestfs/src/libguestfs-1.28.1/perl/. ./.
Makefile:1761: recipe for target 'Makefile-pl' failed
make[2]: [Makefile-pl] Error 1 (ignored)
perl Makefile.PL INSTALLDIRS=site PREFIX=/usr
Only one of PREFIX or INSTALL_BASE can be given. Not both.
Makefile:1761: recipe for target 'Makefile-pl' failed
make[2]: *** [Makefile-pl] Error 2

rwmjones commented on 2014-10-21 08:58

virt-p2v requires Gtk2 (C libs) since it has a small graphical front end.

In Fedora we then take the virt-p2v binary and package it into an ISO (containing a full OS etc) so people can boot it on their physical machines to perform physical to virtual conversions. However you don't need to do all this as there is a script ('virt-p2v-make-disk') which end users can run to achieve the same thing.

The website gets updated automatically when we do a development release (not a stable one like this). I'm sure we'll be doing a dev release in a few days ...

skalkoto commented on 2014-10-21 08:40

@rwmjones virt-p2v is not enabled on my system when I build the package. As far as I've seen it's written in C. Does it have any dependencies?

Also, you probably need to update the front page in http://libguestfs.org/
It states:

Latest development version: 1.27.64 (released 2014-10-17).
Stable branches: 1.26.x, Old stable: 1.24.x, 1.22.x, 1.20.x

:-)

skalkoto commented on 2014-10-21 08:25

1.28.1-1

* New upstream version

rwmjones commented on 2014-10-18 14:24

1.28 has been released:
https://www.redhat.com/archives/libguestfs/2014-October/msg00138.html

skalkoto commented on 2014-10-01 09:04

1.26.9-1

* New upstream version

axil42 commented on 2014-09-26 13:57

I have qemu 2.1.1, so I don't think this was the issue.

It worked after a reboot (I guess). Didn't have the chance to add the debug flags prior to rebooting as it was a force poweroff due to power cut :/

Thanks anyway ;)

rwmjones commented on 2014-09-26 11:04

You need to add the debugging flags (-v -x) to see the real problem. I'm guessing it's because qemu-img is too old however.

axil42 commented on 2014-09-26 10:45

Hi! Just upgraded to latest 1.26.8 and I encountered this error with virt-builder, anyone else can reproduce it? System is updated ([testing] repo NOT enabled).

virt-builder debian-7 --format qcow2 --size 20G --root-password file:/tmp/passwd
virt-builder: libguestfs error: qemu-img: debian-7.qcow2: qemu-img exited with error status 1.

Full log here: http://www.fpaste.org/136698/

skalkoto commented on 2014-09-01 14:34

1.26.8-1

* New upstream version

skalkoto commented on 2014-08-20 12:41

1.26.7-1

* New upstream version
* Used the improvements proposed by Lekensteyn

skalkoto commented on 2014-08-20 12:40

1.26.5-1

* New upstream version
* Used the improvements proposed by Lekensteyn

gabx commented on 2014-08-11 18:10

I am not sure to fully undertsand the appliance story.
Git package build with these configure options:
./configure \
--disable-appliance \
--without-java \
--disable-lua \
--disable-erlang \
--disable-php \
--disable-haskell \
--disable-ruby \
--disable-gobject \
--disable-golang
and the update-libguestfs-apppliance.

Now, removing the configure option disable-appliance and the two related files in PKGBUILD, build breaks:

error: failed to update core (unable to lock database)
error: failed to update extra (unable to lock database)
error: failed to update community (unable to lock database)
error: failed to update multilib (unable to lock database)
error: failed to synchronize any databases
error: failed to init transaction (unable to lock database)
error: could not lock database: Permission denied
--2014-08-11 20:00:15-- https://aur.archlinux.org/packages/e2/e2fsprogs/e2fsprogs.tar.gz
Resolving aur.archlinux.org (aur.archlinux.org)... 5.9.250.164, 2a01:4f8:160:3033::2
Connecting to aur.archlinux.org (aur.archlinux.org)|5.9.250.164|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2014-08-11 20:00:15 ERROR 404: Not Found.

First, it is https://aur.archlinux.org/packages/e2fsprogs-git

Then, I need to su to unloack database !

Last, the virt-p2v and virt-v2v are not installed in /usr/bin

gabx commented on 2014-08-11 16:33

Thank you to Richard.W.M Jonesand his big reactivity on the list.

I will post soon the libguestfs-git AUR package

rwmjones commented on 2014-08-10 11:20

-ENOINFO. Post the precise error messages on the libguestfs mailing list (libguestfs@redhat.com). You don't have to subscribe.

gabx commented on 2014-08-10 11:12

i just built from git, but got error on building virt-p2v :-(

rwmjones commented on 2014-08-10 11:03

virt-v2v & virt-p2v are in 1.27 (development) and future 1.28 (stable).

gabx commented on 2014-08-10 10:46

Looking at the libguestfs git https://github.com/libguestfs/libguestfs, and comparing to the tarball, it seems there are some diff, especially the p2v command.

gabx commented on 2014-08-10 10:27

First, thank you for your package.

I built the package but can not see /usr/bin/virt-p2v.
According to http://libguestfs.org, this is part of libguestfs.

What is wrong?

skalkoto commented on 2014-08-08 14:09

I don't know,
I can give it a try but the archlinux package names have changed many times and every time this happens until the next version of libguestfs is out, this package will be broken. Before we started using the binary appliance the package used to be broken all the time. This one just works.

rwmjones commented on 2014-08-08 13:51

supermin 5 works a bit differently from earlier versions. As long as actual package names don't change it shouldn't be fragile.

skalkoto commented on 2014-08-08 13:44

Yes. I used the "binary appliance" approach because the rolling-releases philosophy of archlinux, makes the libguestfs appliance creation rather fragile. The library needs to be patched all the time because archlinux packages change very fast and I wanted to have a package that always worked.

rwmjones commented on 2014-08-08 13:29

This is not as it sounds. Libguestfs does not use a "binary appliance". It uses an appliance which is normally built on the fly from the installed programs and libraries on the host.

http://libguestfs.org/supermin.1.html#SUPERMIN-APPLIANCES

supermin 5 supports ArchLinux, and it's perfectly possible to do what we do on Fedora which is to build the appliance on the fly. The current ArchLinux packaging downloads the prebuilt appliance that we supply (copied from a Fedora machine), but it doesn't have to be this way.

gdamjan commented on 2014-08-08 13:20

@skalkoto "The package needs a binary-appliance in order to work."

for all the tools?

skalkoto commented on 2014-08-06 12:21

@Lekensteyn I'll try to adopt most of the changes you suggest ASAP.

@gdamjan The package needs a binary-appliance in order to work. This appliance is big (100M compressed). The most natural thing to do is to download it when you install the package. In other distro's like Debian were the appliance is constructed with supermin (http://people.redhat.com/~rjones/supermin/) it is done in the post-install by executing update-guestfs-appliance and you can recreate it at any time by re-running the command. I don't think that creating a 300MB package that contains the appliance is a good thing to do. Besides this, if we implement the caching mechanism, we may be able to update (between minor releases) without downloading the appliance again.

gdamjan commented on 2014-08-06 10:29

Why does the package download* stuff on install?
[*] http://libguestfs.org/download/binaries/appliance/appliance-1.26.0.tar.xz
Can't that be put in the package?
or even better a separate opt-depends package

rwmjones commented on 2014-08-04 08:34

> Is there a list of dependencies needed for each component?

Unfortunately not in a very convenient form. You can read the README file, but that just gives a list of all dependencies. Or you can run ./configure and at the end it will tell you which tools are going to be built (but not why they aren't going to be built). In this case you want:

OCaml-based virt tools .............. yes

Lekensteyn commented on 2014-08-04 08:30

@rwmjones Oh, I thought of OCaml as in language bindings for a developer, not actual tools. The `./configure --help` output did not suggest otherwise. Is there a list of dependencies needed for each component?

rwmjones commented on 2014-08-04 08:30

Also `make check' should not fail. If it does fail it indicates that you've got real bugs in the rest of the distro. The libguestfs test suite is a great way to test that your distro supports virtualization properly.

Almost all tests can be skipped individually if there are specific failures that you don't want to fix immediately.

rwmjones commented on 2014-08-04 08:26

BTW disabling OCaml disables several useful tools:

- virt-resize
- virt-sparsify
- virt-sysprep
- virt-customize
- virt-builder
- virt-v2v (in >= 1.28)

That's quite a large loss of functionality just to save two dependencies.

rwmjones commented on 2014-08-04 08:24

Not signed just because I forgot to do it. I have signed all the 1.26 tarballs now. The slowness is likely because of the server itself. We are looking at other hosting options, but haven't found anything at the moment.

Lekensteyn commented on 2014-08-04 07:19

@rwmjones Any reason why newer versions are not signed? It would also be nice if faster mirrors were available, I am only getting 400 KiB/s in Europe (Netherlands) while I am limited at 4 MiB/s.

@skalkoto Have a look at [1] for a version bump (1.26.7) and improved packaging. Changes:
- Allow the python version to be changed (default to 3 instead of 2). **Note** you may want to set the default to 2, but I needed 3 for my application.
- Disable OCaml to reduce dependencies.
- Disable building static libraries.
- Remove `-j3` from `make`, this option should be set in
/etc/makepkg.conf using MAKEFLAGS.
- To reduce bandwidth usage for RH, and to speed up the installation
process, keep the downloaded appliance cached in /var/cache/guestfs.
- Remove use of temporary directory for the appliance, saving 510 MiB
in /tmp/.
- Fix mixed tabs/spaces, trailing spaces.
- Added check target, disabled due to spurious (?) failures.
- Added file and fuse to depends, removing fuse from makedepends (fixes
namcap warnings).
- Avoid outputting download progress when output is not a tty (e.g. a
file) to avoid spamming adding 1.8k lines to /var/log/pacman.log.

[1]: https://github.com/Lekensteyn/aur/commit/0e73d6f

rwmjones commented on 2014-07-31 08:02

Two things:

(1) libguestfs upstream should support either version of Python. The bindings will adapt to the installed version, and/or you can set the PYTHON variable to point to the particular Python (binary) you want to use. eg:

PYTHON=/usr/bin/python3 ./configure

(2) Debian builds and packages libguestfs against multiple versions of Python. They have a very complex build system:

http://anonscm.debian.org/cgit/pkg-libvirt/libguestfs.git/tree/debian/rules?h=experimental

skalkoto commented on 2014-07-31 07:56

@phazen18 Supporting both versions of python would be nice, but I'm not thrilled with the idea of abandoning python2 in favor of python3. This would break snf-image-creator and probably other software too.

phazen18 commented on 2014-07-28 21:53

Any chance of switching the python bindings over to using python3?

skalkoto commented on 2014-07-06 16:14

1.26.5-1

* New upstream version

skalkoto commented on 2014-06-14 12:24

1.26.3-1

* New upstream version

skalkoto commented on 2014-05-20 08:33

@gabx: No problem!

gabx commented on 2014-05-20 08:23

TY for your quick update

skalkoto commented on 2014-05-19 20:04

1.26.2-1

* New upstream version

gabx commented on 2014-05-19 15:09

configure gave an error.
/usr/bin/qemu-system-x86_64 version must be >= 1.
Qemu is up-to-date:
root@hortensia ➤➤ /developement # mypac qemu
698:qemu 2.0.0-3

1.26.2 solved this issue

gabx commented on 2014-05-19 14:02

configure gave an error.
/usr/bin/qemu-system-x86_64 version must be >0 1.
Qemu is up-to-date:
root@hortensia ➤➤ /developement # mypac qemu
698:qemu 2.0.0-3

axil42 commented on 2014-04-28 21:53

@omangold: Ιnstall `base-devel` which contains the needed packages. You are expected to install this if you want to use the AUR.

omangold commented on 2014-04-28 08:53

I would like to report a bug. Flex and bison should be added in makedepends:

checking for flex... no
checking for lex... no
checking for bison... bison -y
configure: error: in `/tmp/yaourt-tmp-root/aur-libguestfs/src/libguestfs-1.26.0':
configure: error: GNU 'flex' is required.

skalkoto commented on 2014-04-10 09:27

1.26.0-1

* New upstream version

skalkoto commented on 2014-03-13 09:58

1.24.8-1

* New upstream version
* Disable golang bindings

@famz: sorry about waiting that long. I have completely forgotten about this.

famz commented on 2014-03-13 07:26

Still have to manually modify the PKGBUILD to add --disable-golang to get it built.

skalkoto commented on 2014-02-26 11:13

I'll disable the golang bindings in the package. Hope you can live with that.

stronnag commented on 2014-02-25 20:56

It compiles fine for me if I add --disable-golang in configure, otherwise, as I have golang installed, it fails.

go install libguestfs.org/guestfs: open /usr/lib/go/pkg/linux_amd64/libguestfs.org/guestfs.a: permission denied
Makefile:1809: recipe for target 'pkg/linux_amd64/libguestfs.org/guestfs.a' failed
make[2]: *** [pkg/linux_amd64/libguestfs.org/guestfs.a] Error 1
make[2]: Leaving directory '/tmp/packerbuild-1000/libguestfs/libguestfs/src/libguestfs-1.24.6/golang'

This is a build as unpriv user, so the go install to the system dir fails.

The go problem is that go install tries to use the normal system root, vice the pkgbuild 'root'. If you (bad) build as root, then the pkg install fails, as the install to the package location did not happen (it's been 'go installed' in the system directory.

Hope that makes sense.

skalkoto commented on 2014-02-25 06:32

It compiles just fine on my side. Does it fail on golang? I don't have golang installed and as far as I see it is not explicitly disabled in ./configure. Can you add --disable-golang in configure and recompile it to see how it goes?

patryk commented on 2014-02-24 20:05

/bin/install -c -m 644 ./pkg/linux_amd64/libguestfs.org/guestfs.a '/tmp/yaourt-tmp-root/aur-libguestfs/pkg/libguestfs/usr/lib/go/pkg/linux_amd64/libguestfs.org/guestfs'
/bin/install: cannot stat './pkg/linux_amd64/libguestfs.org/guestfs.a': No such file or directory
Makefile:1483: recipe for target 'install-golangpkgDATA' failed
make[2]: *** [install-golangpkgDATA] Error 1
make[2]: Leaving directory '/tmp/yaourt-tmp-root/aur-libguestfs/src/libguestfs-1.24.6/golang'
Makefile:1668: recipe for target 'install-am' failed
make[1]: *** [install-am] Error 2
make[1]: Leaving directory '/tmp/yaourt-tmp-root/aur-libguestfs/src/libguestfs-1.24.6/golang'
Makefile:1827: polecenia dla obiektu 'install-recursive' nie powiodły się
make: *** [install-recursive] Błąd 1

skalkoto commented on 2014-02-24 06:16

1.24.6-1

* New upstream version

skalkoto commented on 2014-01-06 11:36

1.24.4-1

* New upstream version

skalkoto commented on 2013-12-10 14:47

1.24.2-1

* New upstream version

skalkoto commented on 2013-12-10 14:46

1.24.1-1

* New upstream version

WhiteAnthrax commented on 2013-12-10 12:07

1.24.2 released
libguestfs-1.24.2.tar.gz 06-Dec-2013 20:06

celebdor commented on 2013-11-20 17:46

Flagged as out of date so that there is a release with rwmjones bug. If there is a git repo for the pkgbuild I can send a pull req.

rwmjones commented on 2013-11-19 09:14

This turned out to be a bug in libguestfs. It was not explicitly
adding libselinux to the link command (but instead that was being
satisfied from some dependent library, probably libvirt).

I have pushed the following commit upstream which should fix this:

https://github.com/libguestfs/libguestfs/commit/acce28e8874e08acce0a6cd7a6703043a1e4ec25

rwmjones commented on 2013-11-18 15:07

I would really have to see the complete, unedited build log to work out what is going on here.

skalkoto commented on 2013-11-17 12:53

Me too

axil42 commented on 2013-11-17 10:15

I just built it manually without any problems.

celebdor commented on 2013-11-17 00:13

Fails to build with yaourt

make[2]: Entering directory '/tmp/yaourt-tmp-celebdor/aur-libguestfs/src/libguestfs-1.24.1/examples'
CCLD create-disk
CCLD debug-logging
CCLD display-icon
../src/.libs/libguestfs.so: undefined reference to `context_type_set'
../src/.libs/libguestfs.so: undefined reference to `context_str'
../src/.libs/libguestfs.so: undefined reference to `context_new'
../src/.libs/libguestfs.so: undefined reference to `getcon'
../src/.libs/libguestfs.so: undefined reference to `setfilecon'
../src/.libs/libguestfs.so: undefined reference to `setsockcreatecon'
../src/.libs/libguestfs.so: undefined reference to `freecon'
../src/.libs/libguestfs.so: undefined reference to `context_free'
collect2: error: ld returned 1 exit status
Makefile:1717: recipe for target 'debug-logging' failed
make[2]: *** [debug-logging] Error 1
make[2]: *** Waiting for unfinished jobs....
../src/.libs/libguestfs.so: undefined reference to `context_type_set'
../src/.libs/libguestfs.so: undefined reference to `context_str'
../src/.libs/libguestfs.so: undefined reference to `context_new'
../src/.libs/libguestfs.so: undefined reference to `getcon'
../src/.libs/libguestfs.so: undefined reference to `setfilecon'
../src/.libs/libguestfs.so: undefined reference to `setsockcreatecon'
../src/.libs/libguestfs.so: undefined reference to `freecon'
../src/.libs/libguestfs.so: undefined reference to `context_free'
collect2: error: ld returned 1 exit status
Makefile:1713: recipe for target 'create-disk' failed
make[2]: *** [create-disk] Error 1
../src/.libs/libguestfs.so: undefined reference to `context_type_set'
../src/.libs/libguestfs.so: undefined reference to `context_str'
../src/.libs/libguestfs.so: undefined reference to `context_new'
../src/.libs/libguestfs.so: undefined reference to `getcon'
../src/.libs/libguestfs.so: undefined reference to `setfilecon'
../src/.libs/libguestfs.so: undefined reference to `setsockcreatecon'
../src/.libs/libguestfs.so: undefined reference to `freecon'
../src/.libs/libguestfs.so: undefined reference to `context_free'
collect2: error: ld returned 1 exit status
Makefile:1721: recipe for target 'display-icon' failed

celebdor commented on 2013-11-17 00:12

Fails to build:

make[2]: Entering directory '/tmp/yaourt-tmp-celebdor/aur-libguestfs/src/libguestfs-1.24.1/examples'
CCLD create-disk
CCLD debug-logging
CCLD display-icon
../src/.libs/libguestfs.so: undefined reference to `context_type_set'
../src/.libs/libguestfs.so: undefined reference to `context_str'
../src/.libs/libguestfs.so: undefined reference to `context_new'
../src/.libs/libguestfs.so: undefined reference to `getcon'
../src/.libs/libguestfs.so: undefined reference to `setfilecon'
../src/.libs/libguestfs.so: undefined reference to `setsockcreatecon'
../src/.libs/libguestfs.so: undefined reference to `freecon'
../src/.libs/libguestfs.so: undefined reference to `context_free'
collect2: error: ld returned 1 exit status
Makefile:1717: recipe for target 'debug-logging' failed
make[2]: *** [debug-logging] Error 1
make[2]: *** Waiting for unfinished jobs....
../src/.libs/libguestfs.so: undefined reference to `context_type_set'
../src/.libs/libguestfs.so: undefined reference to `context_str'
../src/.libs/libguestfs.so: undefined reference to `context_new'
../src/.libs/libguestfs.so: undefined reference to `getcon'
../src/.libs/libguestfs.so: undefined reference to `setfilecon'
../src/.libs/libguestfs.so: undefined reference to `setsockcreatecon'
../src/.libs/libguestfs.so: undefined reference to `freecon'
../src/.libs/libguestfs.so: undefined reference to `context_free'
collect2: error: ld returned 1 exit status
Makefile:1713: recipe for target 'create-disk' failed
make[2]: *** [create-disk] Error 1
../src/.libs/libguestfs.so: undefined reference to `context_type_set'
../src/.libs/libguestfs.so: undefined reference to `context_str'
../src/.libs/libguestfs.so: undefined reference to `context_new'
../src/.libs/libguestfs.so: undefined reference to `getcon'
../src/.libs/libguestfs.so: undefined reference to `setfilecon'
../src/.libs/libguestfs.so: undefined reference to `setsockcreatecon'
../src/.libs/libguestfs.so: undefined reference to `freecon'
../src/.libs/libguestfs.so: undefined reference to `context_free'
collect2: error: ld returned 1 exit status
Makefile:1721: recipe for target 'display-icon' failed

skalkoto commented on 2013-11-13 10:53

1.24.1-1

* New Upstream Version

skalkoto commented on 2013-11-13 10:00

@stiost: I'll try to compile the latest release 1.24.1 and I'll check this too.
Thank you

stiost commented on 2013-11-13 09:29

I had to add vmchannel_test=no to the configure step, or it would fail saying I had an old or non-working QEMU.

skalkoto commented on 2013-10-22 14:18

1.24.0-1

* New Upstream Version

skalkoto commented on 2013-08-29 13:40

1.22.6-1

* New Upstream Version

skalkoto commented on 2013-08-19 09:23

1.22.5-2

* Updated binary appliance to version 1.22.5

rwmjones commented on 2013-08-14 20:11

Hi, can you update the appliance link to:
http://libguestfs.org/download/binaries/appliance/appliance-1.22.5.tar.xz

sha512sum is: be3e8f46c80d65dd19ef12b49fcd6d404ace903dcf278ab221edb3536af128149a6a7bc2e1c59940520fbb9bae342979ce8376cfaa7f3694fac6c1fa9c991236

The reason is that the old appliance is incompatible and causes
some errors. See:
https://bugzilla.redhat.com/show_bug.cgi?id=997160#c2

skalkoto commented on 2013-07-28 08:25

1.22.5-1

* New Upstream Version

patryk commented on 2013-07-10 14:20

since last update I have error
libguestfs: trace: add_drive "/mnt/d/virtual/qemu/windows7_4-1.img" "readonly:true" "format:raw"
libguestfs: trace: add_drive = 0
libguestfs: trace: launch
libguestfs: trace: get_tmpdir
libguestfs: trace: get_tmpdir = "/tmp"
libguestfs: trace: launch = -1 (error)

from guestfs-browser

skalkoto commented on 2013-07-10 08:06

1.22.4-1

* New Upstream Version

patryk commented on 2013-06-24 11:01

thanks :)

skalkoto commented on 2013-06-24 08:50

1.22.3-1

* New Upstream Version
* Changed the location of update-libguestfs-appliance from /usr/sbin to /usr/bin

patryk commented on 2013-06-22 22:14

I cant develop this package if you dont have time .

patryk commented on 2013-06-21 13:49

1.22.3

skalkoto commented on 2013-06-04 09:24

1.22.2-1

* New Upstream Version
* Using binary appliance-1.22.0.tar.xz

aitix commented on 2013-06-02 19:34

I had to apply this patch (see the second diff which patches podwrapper.pl.in), otherwise I got a compile error: https://www.redhat.com/archives/libguestfs/2013-May/msg00093.html

Furthermore, appliance-1.20.0.tar.xz has been removed from http://libguestfs.org/download/binaries/appliance/. It seems to work with appliance-1.22.0.tar.xz.

patryk commented on 2013-05-18 09:32

thanks, now guestfs-browser compile.

skalkoto commented on 2013-05-18 08:48

1.20.6-1

New Upstream Version

ras0ir commented on 2013-04-17 19:16

1.20.6 is available.

skalkoto commented on 2013-03-24 11:13

@Sacro Well, I don't think the binary appliance should be part of the package. It gets created when installing the package and once the package is installed you can update or change it if you want.

The appliance isn't part of any package in Debian/Ubuntu either. They don't use a binary appliance but the files created by the "update-guestfs-appliance" script under "/usr/lib/guestfs/supermin.d" are not part of any package.

Sacro commented on 2013-03-22 09:34

Please don't place untracked files onto the filesystem, you should grab it as part of the PKGBUILD.

skalkoto commented on 2013-03-20 12:02

1.20.4-1

New Upstream Version

skalkoto commented on 2013-03-20 12:01

1.20.4-1

New Upstream Version

skalkoto commented on 2013-02-15 16:49

1.20.2-1

New Upstream Version

skalkoto commented on 2013-01-21 11:07

1.20.1-4

* Add missing cpio dependency
* Remove non-existing --disable-gjs option

axil42 commented on 2013-01-20 20:49

Since febootstrap is commented out in PKGBUILD, cpio is not provided and therefore libguestfs doesn't build. Maybe adding it in deps would be proper.

skalkoto commented on 2013-01-12 18:11

1.20.1-3

* Add pre_upgrade and post_upgrade actions.
* In update-libguestfs-appliance check if the scripts runs as root

skalkoto commented on 2013-01-12 14:49

1.20.1-2

Since the "febootstrap: error: /lib appears as both directory and ordinary file (glibc, ntfs-3g)" issue persists, for now I think it's better to use the official binary appliance than let libguestfs create one during building. The problem is that ntfs-3g package contains an empty /lib dir that confuses febootstrap since in glic pkg /lib is a link to /usr/lib. Take a look at here
for a more detailed explaination: http://goo.gl/OrLza
The issue is reported by ebal (https://aur.archlinux.org/account/ebal) and has been fixed upstream: http://goo.gl/GnrmH but it hasn't reached a package yet. If you still want to compile a new appliance, you need to set up a local arch repository and provide a patched version of ntfs-3g from there.

In this version of libguestfs package I've completely disabled the appliance and wrote a script (update-libguestfs-appliance) that downloads and installs an official binary one from http://www.libguestfs.org/download/binaries/appliance/. The script runs during the post_install phase and is under /usr/sbin. After the installation of libguestfs you can rerun the script as many times you want without problem.

Even if the ntfs-3g package issue is addressed, maybe we should still stick with the binary appliance approach. The rolling-releases philosophy of archlinux, makes libguestfs compilation rather fragile. Any comments on that?

Finally, most library bindings have been disabled. I've only left python, perl and ocaml.

skalkoto commented on 2013-01-07 07:50

@chenxiaolong: Well, ebal told me the same thing about the libguestfs bindings, so I guess this is the way to go. He submitted the febootstrap patches in 3.21 that made febootstrap work with recent versions of pacman and AUR and has also provided me his version of PKGBUILD for libguestfs.

If this was a binary package of libguestfs I would have created different packages for the bindings. This is what debian and fedora do but for a source distribution of the package like AUR there is no point in doing that.

As you have seen, I've also removed 99-guestfsd.rules guestfsd.service and the enable daemon option. Those are needed for creating the libguestfs-live-service
package that contains the guestfsd. This is needed for making a live system work as appliance. I don't think we need this.





chenxiaolong commented on 2013-01-06 21:01

@skalkoto: I have just updated the febootstrap package. No PKGBUILD modifications should be necessary now.

As for the bindings, I'd say we disable them by default and add a comment in the PKGBUILD about how to enable them. They do take a very long time to compile and no packages are using the bindings.

skalkoto commented on 2013-01-06 13:09

1.20.1

You need the latest febootstrap (3.21). Either change the PKGBUILD of febootstrap or use febootstrap-git. All bindings except java are enabled. I couldn't make this work. It takes ages to compile! Do we need all the bindings?

chenxiaolong commented on 2012-12-17 17:45

@skalkoto: Looks like you figured out how to take over the package :)

To update the package, just download the tarball, make the changes to the PKGBUILD, run "makepkg --source", and upload the new tarball at the "Submit" link near the top of the page.

skalkoto commented on 2012-12-17 09:26

I can became the maintain of the package if you want. What do I need to do to take over the package?

chenxiaolong commented on 2012-12-16 22:59

I'm sorry to say I can no longer maintain this package. There are some issues preventing me from using Arch as my VM host.

I will orphan this package so someone else can maintain it :)

stronnag commented on 2012-11-22 18:41

And if you remove zfs-fuse from the image creation, it fails a bit later on:
febootstrap: error: /lib appears as both directory and ordinary file (glibc, ntfs-3g)
make[2]: *** [stamp-supermin] Error 1
make[2]: Leaving directory `/tmp/packerbuild-1000/libguestfs/libguestfs/src/libguestfs-1.18.7/appliance'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/packerbuild-1000/libguestfs/libguestfs/src/libguestfs-1.18.7'
make: *** [all] Error 2
==> ERROR: A failure occurred in build().
Aborting...

CyrIng commented on 2012-11-04 11:27

Does not end building script :

error: target not found: zfs-fuse
--2012-11-04 12:19:18-- http://aur.archlinux.org/packages/zfs-fuse/zfs-fuse.tar.gz
Resolving aur.archlinux.org (aur.archlinux.org)... 78.46.78.247, 2a01:4f8:120:34c2::2
Connecting to aur.archlinux.org (aur.archlinux.org)|78.46.78.247|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://aur.archlinux.org/packages/zfs-fuse/zfs-fuse.tar.gz [following]
--2012-11-04 12:19:18-- https://aur.archlinux.org/packages/zfs-fuse/zfs-fuse.tar.gz
Connecting to aur.archlinux.org (aur.archlinux.org)|78.46.78.247|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2012-11-04 12:19:19 ERROR 404: Not Found.

==> ERROR: Makepkg was unable to build libguestfs.

chenxiaolong commented on 2012-06-07 20:14

@skalkoto: Thanks for the link. As for Fedora, I've tried compiling libguestfs in rawhide, which has a slightly higher version of glibc (librt.so). It compiled successfully. I also did a diff between the 1.16.x and 1.18.x versions, but I couldn't find any changes that greatly affected the build system.

skalkoto commented on 2012-06-07 17:39

For a more "official" explanation take a look at the manual: http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

"It makes a difference where in the command you write this option; the linker searches and processes libraries and object files in the order they are specified. Thus, `foo.o -lz bar.o' searches library `z' after file foo.o but before bar.o. If bar.o refers to functions in `z', those functions may not be loaded."

Feel free to report it, but I think it would be better if we came up with a patch. I wonder why do we ran into this and they haven't noticed it yet? Maybe this isn't triggered in Fedora. I don't know. I'll investigate this a little further tonight if I have some spare time.

chenxiaolong commented on 2012-06-06 17:57

@skalkoto: Thanks for the explanation! I had no idea that the linker options had to go after the object files. That would explain why LDFLAGS wouldn't work. Do you know if a bug is already reported for this? If not, I can do that :)

skalkoto commented on 2012-06-06 10:47

@chenxiaolong The problem is that although -lrt is present in the linker command, it is before the object files, which is incorrect. When the linker parses the -lrt option, the dependency for the clock_gettime symbol is not present yet. The content of the LIBS variable is outputted in the end of the linker command and this is why this works, but still, this is a hack. This is definitely a libguestfs building system bug.

chenxiaolong commented on 2012-06-05 20:35

@skalkoto: Wow, after spending countless hours trying to add "-lrt" to LDFLAGS, CFLAGS, Makefile.am files, plain Makefiles, and failing to get it to work, the solution is that simple? :D :D

Thanks for the solution! I'll update to version 1.18.1 and include that line :)

skalkoto commented on 2012-06-05 19:53

@pouar, @chenxiaolong, I was fighting with this for hours last week. Forgot to send the patch. Exporting LIBS="-lrt" before ./configure does the trick:

build() {
...
export LIBS="-lrt"

./configure \
....

chenxiaolong commented on 2012-06-05 18:20

@pouar: I've tried patching the build system numerous ways, but I can't figure out to fix the problem :(

pouar commented on 2012-06-05 16:51

any reason I'm getting this compile-time error?

gettime.c:(.text+0xe): undefined reference to `clock_gettime'

pouar commented on 2012-06-05 16:50

any reason I'm getting this compile-time error?
gettime.c:(.text+0xe): undefined reference to `clock_gettime'

skalkoto commented on 2012-03-10 06:31

Well, I think debian does not enable libnl support in libpcap. This way libvirt end up being linked against only one version of libnl, the one from netcf. In ubuntu they have patched netcf to link against libnl3. This is known to the arch developers (http://mailman.archlinux.org/pipermail/arch-dev-public/2012-February /022522.html) but no one has ported the patch to arch yet. I myself have recompiled libpcap without the use_libnl3_patch and libguestfs terminates normally. The problem is not having 2 different versions of libnl installed in your system. The problem is having an executable linked against both versions.

skalkoto commented on 2012-03-10 06:30

Well, I think debian does not enable libnl support in libpcap. This way libvirt end up being linked against only one version of libnl, the one from netcf. In ubuntu they have patched netcf to link against libnl3. This is known to the arch developers (http://mailman.archlinux.org/pipermail/arch-dev-public/2012-February /022522.html) but no one has ported the patch to arch yet. I myself have recompiled libpcap without the use_libnl3_patch and libguestfs terminates normally. The problem is not having 2 different versions of libnl installed in your system. The problem is having an executable linked against both versions.

skalkoto commented on 2012-03-10 06:29

Well, I think debian does not enable libnl support in libpcap. This way libvirt end up being linked against only one version of libnl, the one from netcf. In ubuntu they have patched netcf to link against libnl3. This is known to the arch developers (http://mailman.archlinux.org/pipermail/arch-dev-public/2012-February /022522.html) but no one has ported the patch to arch yet. I myself have recompiled libpcap without the use_libnl3_patch and libguestfs terminates normally. The problem is not having 2 different versions of libnl installed in your system. The problem is having an executable linked against both versions.

chenxiaolong commented on 2012-03-10 06:00

@skalkoto: Ahh...I see. I've tried the Ubuntu patches and can confirm that it also works to prevent the segfaults. The only problem is that the patches apply the the latest git commit, not 0.1.9. I've tried manually applying the patches in 0.1.9, but it requires more work than that, since it does not compile (in case you're interested: the build logs: http://paste.kde.org/436460/ and the diff after manually applying Ubuntu's patches: http://paste.kde.org/436454/ ).

skalkoto commented on 2012-03-09 22:21

Well, I think debian does not enable libnl support in libpcap. This way libvirt end up being linked against only one version of libnl, the one from netcf. In ubuntu they have patched netcf to link against libnl3. This is known to the arch developers (http://mailman.archlinux.org/pipermail/arch-dev-public/2012-February /022522.html) but no one has ported the patch to arch yet. I myself have recompiled libpcap without the use_libnl3_patch and libguestfs terminates normally. The problem is not having 2 different versions of libnl installed in your system. The problem is having an executable linked against both versions.

skalkoto commented on 2012-03-09 22:20

Well, I think debian does not enable libnl support in libpcap. This way libvirt end up being linked against only one version of libnl, the one from netcf. In ubuntu they have patched netcf to link against libnl3. This is known to the arch developers (http://mailman.archlinux.org/pipermail/arch-dev-public/2012-February /022522.html) but no one has ported the patch to arch yet. I myself have recompiled libpcap without the use_libnl3_patch and libguestfs terminates normally. The problem is not having 2 different versions of libnl installed in your system. The problem is having an executable linked against both versions.

skalkoto commented on 2012-03-09 22:17

Well, I think debian does not enable libnl support in libpcap. This way libvirt end up being linked against only one version of libnl, the one from netcf. In ubuntu they have patched netcf to link against libnl3. This is known to the arch developers (http://mailman.archlinux.org/pipermail/arch-dev-public/2012-February /022522.html) but no one has ported the patch to arch yet. I myself have recompiled libpcap without the use_libnl3_patch and libguestfs terminates normally.

chenxiaolong commented on 2012-03-09 21:30

That bug is going to be a problem: I looked at Fedora's koji build system and it seems that they packaged both libnl and libnl3. Debian and openSUSE are doing the same, so I don't think there's much we can do to have netcf or libvirt ported to libnl3. The Arch Linux packagers will probably need to use some workarounds to fix the libvirt segfaults.

chenxiaolong commented on 2012-03-09 21:13

@skalkoto: Unfortunately, "libguestfs-test-tool" segfaults. Here is the log: http://paste.kde.org/436250/ The weird thing is that it segfault right after in said that the "TEST FINISHED OK".

Anonymous comment on 2012-03-09 17:50

tnk it build :D

skalkoto commented on 2012-03-09 17:24

Hello chen, the "make check" segfault is probably related to libvirt. Take a look at this: https://bugs.archlinux.org/task/28735

If you execute "libguestfs-test-tool", does it finish without creating a segfault?

chenxiaolong commented on 2012-03-09 17:14

I've updated this package to the latest 1.16.9 :) I also hit the error when building with the ocaml bindings. The only thing on could find about the issue was this, http://pastebin.com/74C0bCmM , which isn't very useful. I currently have ocaml stuff disabled in the PKGBUILD.

I also had to disable gobject-introspection and "make check", since both of them cause segfaults during the build :(

chenxiaolong commented on 2012-03-08 17:44

@skalkoto & pennega: Thanks! I've been pretty busy lately and haven't had time to update this package, but now it's spring break at my school, so I'll be able to update this later on today :)

skalkoto commented on 2012-03-08 14:34

I would start by disabling ocaml (pass --disable-ocaml to configure)

Anonymous comment on 2012-03-08 14:22

I'm try to build the 1.16.8 but it fail
[code]
ocamldoc -d html -html guestfs.mli guestfs.ml
Warning: Element Unix.error not found
ocamlfind ocamlc -g -warn-error CDEFLMPSUVYZX -package unix -c bindtests.ml -o ./bindtests.cmo
mkdir -p t
LD_LIBRARY_PATH=../src/.libs \
ocamlfind ocamlc -g -warn-error CDEFLMPSUVYZX -I . -package unix -linkpkg mlguestfs.cma bindtests.cmo -o bindtests.bc
ocamlc.opt got signal and exited
make[2]: *** [bindtests.bc] Error 2
make[2]: Leaving directory `/home/pennega/software/libguestfs/1.16.6/libguestfs/src/libguestfs-1.16.8/ocaml'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/pennega/software/libguestfs/1.16.6/libguestfs/src/libguestfs-1.16.8'
make: *** [all] Errore 2
[/code]

skalkoto commented on 2012-03-08 13:12

Hello pennega and chenxiaolong, 1.16.7 and 1.16.8 should work. I sent a patch to libguestfs a week ago to make the libguestfs appliance work with an up-to-date arch linux system and it was included in 1.16.7. I have a working 1.16.6 package (patched) on my system but I only have python bindings enabled. I had problems with java. libguestfs did not correctly detect the JAVA_HOME and configure failed.

Anonymous comment on 2012-03-08 10:24

hi chen
i have adopted the hivex pkg, if you want (or have time) try to compile the new libguestfs, i'm try it now :D

chenxiaolong commented on 2011-12-17 22:16

There's now a proper fix for the issue, so I removed the patch. The fix, however, requires the 'qemu-kvm-spice' package to be updated (I posted a comment there).

Anonymous comment on 2011-12-17 17:30

tnk

chenxiaolong commented on 2011-12-17 17:05

Okay, Richard from Red Hat has been really helpful in trying to fix the issue (https://bugzilla.redhat.com/show_bug.cgi?id=768508). I've included his temporary patch/hack to workaround the issue. The bug is caused when "-vga cirrus" is mussing from the qemu command line and then attempting to load virtio-blk.ko in the appliance.

I've included the patch in the PKGBUILD. Although a little 'hackish,' everything should work fine now.

chenxiaolong commented on 2011-12-16 22:21

I've removed "make check" from the PKGBUILD for now.

chenxiaolong commented on 2011-12-16 19:56

Hmm...even the 1.15.11 development version won't work. I guess we'll have to comment out the check() part of the PKGBUILD until libguestfs supports Qemu 1.0

chenxiaolong commented on 2011-12-16 19:25

Okay, I can reproduce the problem now. It seems to be caused by the update to qemu 1.0.

chenxiaolong commented on 2011-12-15 15:15

fs_types.h doesn't not exist in /usr/include or /usr/src on my computer.

Anonymous comment on 2011-12-15 10:24

fuse in my system work, i use acetoneiso2, truecrypt ntfs-3g...
i send the configure log via email.
you have file fs_types.h ? in which package

chenxiaolong commented on 2011-12-15 04:13

I'm still unable to reproduce the issue. When I searched for the error message, there were quite a few results mentioning fuse . Do you know if fuse works properly for you (ie. ntfs-3d, sshfs, etc.)?

chenxiaolong commented on 2011-12-15 01:54

Could you post the full build log at a site like http://pastie.org ? Maybe that can help me find the cause of the problem.

In the meantime, I'm recompiling both febootstrap and libguestfs to try to reproduce the problem.

Anonymous comment on 2011-12-15 00:43

the result is the same :(

Anonymous comment on 2011-12-15 00:08

i have upgradate the system now the kernel is 3.1.5-1-ARCH...
i'm waiting the end of the compilation

Anonymous comment on 2011-12-14 23:19

the kernel is the current in arch (3.1.4-1-ARCH)
the file /etc/sysctl.conf contains
net.ipv4.ip_forward=1
kernel.sysrq = 0
net.ipv4.tcp_syncookies = 1
fs.inotify.max_user_watches = 524288

the file /etc/sysctl.d/libvirtd contains
fs.aio-max-nr = 1048576

chenxiaolong commented on 2011-12-14 22:44

@pennega: Are you using a custom kernel and have you modified anything in /etc/sysctl* ? I can't seem to reproduce the issue in an Arch Linux VM :(

Anonymous comment on 2011-12-14 20:48

hi i'm trying to compile this pkg but when makepkg execute the check function it stop to go and write this messages
....
febootstrap: internal insmod virtio-rng.ko.gz
febootstrap: internal insmod virtio_console.ko.gz
febootstrap: internal insmod virtio_pci.ko.gz
febootstrap: internal insmod virtio_balloon.ko.gz
febootstrap: internal insmod virtio_blk.ko.gz
[ 240.336813] INFO: task init:1 blocked for more than 120 seconds.
[ 240.338209] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 360.340118] INFO: task init:1 blocked for more than 120 seconds.
[ 360.341445] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 480.343340] INFO: task init:1 blocked for more than 120 seconds.
[ 480.344656] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 600.343463] INFO: task init:1 blocked for more than 120 seconds.
[ 600.345272] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 720.346646] INFO: task init:1 blocked for more than 120 seconds.
[ 720.347954] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 840.347215] INFO: task init:1 blocked for more than 120 seconds.
[ 840.348789] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 960.350023] INFO: task init:1 blocked for more than 120 seconds.
[ 960.351330] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1080.353348] INFO: task init:1 blocked for more than 120 seconds.
[ 1080.354901] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1200.356687] INFO: task init:1 blocked for more than 120 seconds.
[ 1200.358332] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1320.359950] INFO: task init:1 blocked for more than 120 seconds.
[ 1320.361280] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

any idea ?

thatch45 commented on 2011-12-12 06:45

@chenxiaolong: Thanks! Orphaned!

Keep in mind that this is a very delicate package, let me know if you need any help with it!

chenxiaolong commented on 2011-12-12 06:43

@thatch45: I'd be glad to maintain both febootstrap and libguestfs. I have a lot of free time available right now :)

thatch45 commented on 2011-12-12 04:42

If someone is interested in maintaining these please let me know! The recent patches to febootstrap and libguestfs should no longer require constant babying and I am running out of time to maintain these things

chenxiaolong commented on 2011-12-12 04:25

@thatch45: Thanks for all your work! In the meantime, here's an updated source package for libguestfs: http://ubuntuone.com/0VJBGNXuWBEXHFPyee9Nzm

I've made many changes to the PKGBUILD. Many of the changes were taken from the Fedora spec file. I've updated a few of the dependencies to enable all the optional features (can be easily disabled of course), reeanabled the 'fakeroot' build option (for a cleaner build), as well as some other stuff.

From my testing, it should be working pretty well :)

thatch45 commented on 2011-11-03 15:40

We are still cleaning up the latest release and we made a lot of additions to the software for Arch support. 1.14 should be up here soon!

thatch45 commented on 2011-04-01 19:31

1.8.4

Some more packaging fixes, I also discovered that libguestfs will not build if you have gcc-libs-multilib installed, I am looking into a fix, until I fix it you will need to ensure that the stock gcc is installed, or build in a chroot

thatch45 commented on 2011-03-11 06:31

I fixed the reboot issue in the install script, libguestfs is back in business!

thatch45 commented on 2011-03-11 05:37

The gzipped kernel change broke libguestfs, now the post instal makes changes in the kernel module tree to make libguestfs work, it also requires a reboot

thatch45 commented on 2011-03-10 18:19

I am aware that this package is out of date, I am working on improving a number of small aspects of this package, and it takes a long time to build and test, I will have an update shortly

thatch45 commented on 2011-01-22 18:37

Updated to 1.8.1

thatch45 commented on 2010-12-31 05:29

Fixed a number of small issues with libguestfs package, many more of the bindings are working now as well. Ruby bindings are not working, the ol' ruby 1.9 issue, and haskell bindings are not working.

thatch45 commented on 2010-12-19 19:02

Libguestfs is ready for primetime!
This package can take a while to build as it needs to build an Archlinux virtual machine appliance, so be patient.

thatch45 commented on 2010-12-13 04:04

This is the initial package release, python and ruby bindings don't work yet because of versioning issues and the package has not been split yet, it also requires febootstrap 3.4, which has not been released yet. The febootstrap should be available very soon.