here is the error log from spice-gtk: checking for USBREDIR... no configure: error: usbredir support explicitly requested, but some required packages are not available Error: * In program cave perform install --hooks --managed-output --output-exclusivity with-others =net-misc/spice-gtk-0.14:0::gentoo --destination installed --replacing =net-misc/spice-gtk-0.12:0::installed --x-of-y 1 of 1: * When installing 'net-misc/spice-gtk-0.14:0::gentoo' replacing { 'net-misc/spice-gtk-0.12:0::installed' }: * When running an ebuild command on 'net-misc/spice-gtk-0.14:0::gentoo': * Install failed for 'net-misc/spice-gtk-0.14:0::gentoo' (paludis::ActionFailedError) !!! ERROR in net-misc/spice-gtk-0.14::gentoo: !!! In econf at line 2624 !!! econf failed !!! Call stack: !!! * econf (/var/tmp/paludis/net-misc-spice-gtk-0.14/temp/loadsaveenv:2624) !!! * src_configure (/var/tmp/paludis/net-misc-spice-gtk-0.14/temp/loadsaveenv:7043) !!! * ebuild_f_configure (/usr/libexec/paludis/2/src_configure.bash:54) !!! * ebuild_main (/usr/libexec/paludis/ebuild.bash:668) !!! * main (/usr/libexec/paludis/ebuild.bash:691) diefunc: making ebuild PID 71534 exit with error die trap: exiting with error. Failed install to / for net-misc/spice-gtk-0.14:0::gentoo replacing 0.12:0::installed (this is with locally bumped usbredir-0.5.2 but the changelog of usbredir suggests that the API compatibility was broken in 0.5 anyway). And the usbredir homepage says: Latest versions: For use with qemu git master: usbredir-0.5.2.tar.bz2 For use with qemu 1.0 / 1.1 / 1.2 release: usbredir-0.4.4.tar.bz2 Proposal: mask or unkeyword usbredir-0.5 until qemu-1.3 (or maybe qemu-1.2.1). Alternative which works for spice-gtk only: pull patches from http://pkgs.fedoraproject.org/cgit/spice-gtk.git/tree/
(In reply to comment #0) and the config.log says what now ? and what USE flags exactly are you using with spice-gtk/qemu ?
USE=usbredir config.log: [...] configure:16936: $PKG_CONFIG --exists --print-errors "libusb-1.0 >= 1.0.9 libusbredirhost >= 0.4.2 libusbredirparser >= 0.4" Package libusbredirparser was not found in the pkg-config search path. Perhaps you should add the directory containing `libusbredirparser.pc' to the PKG_CONFIG_PATH environment variable No package 'libusbredirparser' found configure:16939: $? = 1 configure:16953: $PKG_CONFIG --exists --print-errors "libusb-1.0 >= 1.0.9 libusbredirhost >= 0.4.2 libusbredirparser >= 0.4" Package libusbredirparser was not found in the pkg-config search path. Perhaps you should add the directory containing `libusbredirparser.pc' to the PKG_CONFIG_PATH environment variable No package 'libusbredirparser' found configure:16956: $? = 1 configure:16970: result: no No package 'libusbredirparser' found configure:16999: error: usbredir support explicitly requested, but some required packages are not available but remember: this is with usbredir-0.5.2. With usbredir 0.5.0/0.5.1 configure.ac may work but it may fail further down as suggested by the changelog-entry for usbredir-0.5.2 (I didn't test it): usbredir-0.5.2 15 September 2012 -------------------------------- -usbredirparser: -rename libusbredirparser.pc to libusbredirparser-0.5.pc This should really have been done with the 0.5 release as API compatibility with previous releases was broken there! So: if we already apply backported-patches to qemu which make it build against newer usbredir (Cardoe?) we might have to apply those patches to spice-gtk as well. If not: the easiest solution would be to mask/unkeyword usbredir >= 0.5 since qemu/spice-gtk are the only users afaik.
This is the crappy nature / situation of us carrying some of Fedora's patches which introduce broken APIs since the APIs got modified before being merged upstream. Also some crappy bolt ons that Fedora people got into upstream trees to work around behaviors. They're doing this massive push to get functionality features into "earlier" versions since they can't do version bumps on packages for Fedora 18. Remember Fedora 18 is the basis for RHEL 7 so that adds more craptastic pushes. We lived through this same damn situation a few years back with qemu-kvm 0.12 vs qemu-kvm 0.13. Fedora / RHEL 6 shipped qemu-kvm 0.12 but it was really closer to qemu-kvm 0.13, except the changes were the pre-upstream review APIs and so we had a lot of breakages and changes related to that. Since RedHat people tested against RedHat versions and got code reviews from other RedHat people before merging into the upstream repo. The is the reason why Gentoo still doesn't have an unmasked qemu-1.2.x release. There's just so much breakage floating around between trees. Try to use Ubuntu's packages of 1.2.x with virtio... oops? Where did it go? I don't want to throw more patches and backport more hacks to deal with forward leaning bits. The situation should be qemu-1.0, 1.1, 1.2 use usbredir 0.4 and qemu-1.3 uses usbredir 0.5.
ok, the patch which makes spice-gtk build against usbredir >=0.5.2 says this: *commentsnip* The usbredir 0.5 release introduced the new API for 64 bit packet ids, but it kept the libusbredirparser.pc name as is, meaning that older versions of qemu will still have their pkg-config check for usbredirparser fulfilled, and build with the usb-redir device. Due to the API change there will be some compiler warnings, but the build will succeed, however the usb-redir device will be broken on 32 bit machines. To solve this, the usbredir-0.5.2 release renames the libusbredirparser.pc file to libusbredirparser-0.5.pc, so that it will no longer fulfill the pkg-config check of the qemu-1.2 and older releases, stopping the (silent) breakage. spice-gtk does not use the changed parts of the API, but does use libusbredirparser for the usbredirfilter* functions. This patch adapts spice-gtk's configure to accept both the libusbredirparser-0.5 and the libusbredirparser pkg-config names. *commentsnip* That means that only qemu with USE=usbredir will be broken with usbredir >=0.5 only on 32bit-archs.
(In reply to comment #4) > ok, the patch which makes spice-gtk build against usbredir >=0.5.2 says this: > > *commentsnip* > The usbredir 0.5 release introduced the new API for 64 bit packet ids, but > it kept the libusbredirparser.pc name as is, meaning that older versions of > qemu will still have their pkg-config check for usbredirparser fulfilled, > and build with the usb-redir device. Due to the API change there will be > some compiler warnings, but the build will succeed, however the usb-redir > device will be broken on 32 bit machines. > > To solve this, the usbredir-0.5.2 release renames the libusbredirparser.pc > file to libusbredirparser-0.5.pc, so that it will no longer fulfill the > pkg-config check of the qemu-1.2 and older releases, stopping the (silent) > breakage. > > spice-gtk does not use the changed parts of the API, but does > use libusbredirparser for the usbredirfilter* functions. This patch adapts > spice-gtk's configure to accept both the libusbredirparser-0.5 and the > libusbredirparser pkg-config names. > *commentsnip* > > That means that only qemu with USE=usbredir will be broken with usbredir > >=0.5 only on 32bit-archs. Is that really the route we want to take? We'd have to effectively mask versions for 32-bit or at least do blockers or revert keywords.
I've put the appropriate version depends in the existing ebuilds based on how the code actually looks.
I get the following output when emerging qemu-1.2.1: >>> Configuring source in /var/tmp/portage/app-emulation/qemu-1.2.1/work/qemu-kvm-1.2.0 ... ^[[32;01m*^[[0m Building the following softmmu targets: x86_64-softmmu ERROR ERROR: User requested feature usb-redir ERROR: configure was not able to find it ERROR Is this related or a different bug? config.log does not show anything that appears useful...
*** Bug 448150 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > I get the following output when emerging qemu-1.2.1: > >>> Configuring source in /var/tmp/portage/app-emulation/qemu-1.2.1/work/qemu-kvm-1.2.0 ... > ^[[32;01m*^[[0m Building the following softmmu targets: x86_64-softmmu > ERROR > ERROR: User requested feature usb-redir > ERROR: configure was not able to find it > ERROR > > Is this related or a different bug? config.log does not show anything that > appears useful... This appeared with =usbredir-0.6: the pkgconfig file was called libusbredirparser.pc before, now it is libusbredirparser-0.5.pc (and qemu configure script calls pkgconfig on the former)
For QEMU, this issue is mitigated by the upstream usbredir-0.4.4, which I've added to the tree and QEMU 1.2 and lower will have their depends set correctly. I'll double check our workaround for spice-gtk and handle that appropriately soonish.
Resolved for both spice-gtk and qemu. We use usbredir-0.4.4 for QEMU 1.2 and less and SPICE GTK 0.14 and lower as well. For newer versions we'll use a newer version.
fine by me (for long as nothing else than qemu uses usbredir, it something else would use it, it wouldn't be okay anymore as it would cause up-downgrade "cycle" or at least force downgrade and break the other package in the same stabilization level)
