The package actually in the portage tree is not the genuine Qemu but its "KVM fork" (see where SRC points to), sometimes ago both qemu and qemu-kvm were present and mutually exclusive.... All Qemu ebuilds in the tree as of december 27th are affected.
Taken from qemu-1.1.1-r1 . qemu-1.2.1: if [[ ${PV} = *9999* ]]; then EGIT_REPO_URI="git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git" else SRC_URI="mirror://sourceforge/kvm/${MY_PN}/${MY_P}.tar.gz ${BACKPORTS:+ http://dev.gentoo.org/~cardoe/distfiles/${MY_P}-bp-${BACKPORTS}.tar.xz}" KEYWORDS="amd64 ~ppc ~ppc64 x86 ~x86-fbsd" fi HOMEPAGE="http://www.linux-kvm.org" Taken from qemu-9999: if [[ ${PV} = *9999* ]]; then EGIT_REPO_URI="git://git.qemu.org/qemu.git" else SRC_URI="http://wiki.qemu-project.org/download/${P}.tar.bz2 ${BACKPORTS:+ http://dev.gentoo.org/~cardoe/distfiles/${P}-${BACKPORTS}.tar.xz}" KEYWORDS="~amd64 ~ppc ~ppc64 ~x86 ~x86-fbsd" fi HOMEPAGE="http://www.linux-kvm.org" As stated on the qemu-1.3.0 release announcement[1], qemu-kvm was merged back into qemu on this release, so you'll have to wait for the 1.3 bump to have qemu fetching from qemu again. In the meanwhile, you can use the 9999 version if you want to fetch from the qemu repo. We need to update the home page, though. [1] - http://comments.gmane.org/gmane.comp.emulators.qemu/182727
The ebuild name is misleading for the end user. It is not major as both are close however it is much better to have what it is really....
No. We just got through making this happen to smooth the transition.
It is disppointing to not have a happy end in that case and just a "dry closure" because KVM 1.2.x is broken for MIPS (compilation failure whereas the genuine QEmu does not) when it does not even fail at the configure phase. When Googling for the problem the end user will waste his time because of the misnaming. Anyway QEmu 1.3 is on the way and this probably does not probably worth to reshuffle the cards at this point. However a little note explaining that app/qemu is indeed the KVM branch could have been appreciated by the end user and a sufficient workaround.
(In reply to comment #4) > It is disppointing to not have a happy end in that case and just a "dry > closure" because KVM 1.2.x is broken for MIPS (compilation failure whereas > the genuine QEmu does not) when it does not even fail at the configure > phase. When Googling for the problem the end user will waste his time > because of the misnaming. > > Anyway QEmu 1.3 is on the way and this probably does not probably worth to > reshuffle the cards at this point. However a little note explaining that > app/qemu is indeed the KVM branch could have been appreciated by the end > user and a sufficient workaround. Project is called QEMU if you want to get technical. It builds fine for mips, except for the 1.2.1 ebuild which I assume you're referring to bug #447196. Not going to break out the ebuilds into two different things and deal with all the cross depends because 1 arch doesn't work in ~arch. We package our QEMU the same way most major distros do so it shouldn't really be a surprise.
