Bug 298287 – emerge app-emulation/qemu-kvm-0.12.1.1 freezes whith QEMU_SOFTMMU_TARGETS="" QEMU_USER_TARGETS=""

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Sergey 2009-12-25 05:51:51 UTC]

Emerge app-emulation/qemu-kvm-0.12.1.1 freezes whith QEMU_SOFTMMU_TARGETS="" QEMU_USER_TARGETS=""
It emerges fine with QEMU_SOFTMMU_TARGETS="x86_64" QEMU_USER_TARGETS="x86_64"


Reproducible: Always

Steps to Reproduce:
1.QEMU_SOFTMMU_TARGETS="" QEMU_USER_TARGETS="" emerge qemu-kvm
2.
3.

Actual Results:  
Emerge freezes, no activity.

Expected Results:  
Successful build.

I'm not definitly shure that it is right to emerge qemu-kvm with QEMU_SOFTMMU_TARGETS="" QEMU_USER_TARGETS="", but i think that it is what i should do if i do not want any software emulation. Anyway, there should be some kind of message about it.

[Comment 1 Sergey 2009-12-25 05:57:13 UTC]

Created attachment 214109 [details]
Output of `emerge qemu-kvm`

[Comment 2 PetaMem R&D 2010-01-04 11:11:30 UTC]

Same here. Problem seems to be in the Makefile, where

this target

config-all-devices.mak: $(SUBDIR_DEVICES_MAK)
        $(call quiet-command,cat $(SUBDIR_DEVICES_MAK) | grep =y | sort -u > $@,"  GEN   $@")

Results in this command

/bin/sh -c echo "  GEN   config-all-devices.mak" && cat  | grep =y | sort -u > config-all-devices.mak

So $(SUBDIR_DEVICES_MAK) is effectively left empty (why I don't know) and grep waits forever.

This problem happens also with the 9999 git repository.

[Comment 3 Bjunix 2010-01-16 20:24:12 UTC]

Same here.

[Comment 4 R. David Murray 2010-01-19 17:24:03 UTC]

I'm seeing the same hang on x86 and qemu-kvm-0.12.1.2.

[Comment 5 RumpletonBongworth 2010-01-21 06:18:19 UTC]

Confirmed as still applicable to the recently committed qemu-kvm-0.12.2.

[Comment 6 Doug Goldstein (RETIRED) 2010-01-21 06:37:15 UTC]

(In reply to comment #5)
> Confirmed as still applicable to the recently committed qemu-kvm-0.12.2.
> 

Short answer: Don't disable everything. Invalid configuration.

Long answer: Unfortunately dieing in pkg_setup is no longer a valid thing in Gentoo and since there's no way for an ebuild to express that at least one USE flag must be turned on, you're stuck with this bug. Commenting on each bug saying its still an issue and then opening a stable request is insane.

[Comment 7 RumpletonBongworth 2010-01-21 06:59:52 UTC]

> Commenting on each bug
> saying its still an issue and then opening a stable request is insane.

I see. And continually creating new ebuild versions in portage without attending to even the most trivial QA bugs - not necessarily this one - is not (*)?

As for the stable request bug for 0.12.2, I made that change simply because it made no sense for it to be an ebuild request any longer and was going to go about assisting in determining which of the remaining bugs were resolved in the new version and which were not. In effect, I figured that it could be used as a reference point for blocking some of the existing bugs, so as to say "here, these would be definitely fixed by stabilising 0.12.2 rather than continuing to hope that any contributed patch will be applied in the existing stable version(s)". I suppose it should/could have been a tracker instead. Whatever. if the process of trying to move things forwards in attending to the oustanding bugs is "insane" then stuff it, I won't bother and just chalk up one more for my personal overlay.

(*) There are others which I would have been happy to file on - and provide patches for - if I had the faintest confidence that anyone would incoporate them. See bug 280121 for a prime example which also alludes to other (very real) QA issues within its follow-up comments.

[Comment 8 Thomas Sachau 2010-03-10 18:23:49 UTC]

I added a short message, when no target all all is set. I hope, this is enough for now.