Bug 332145 – app-emulation/qemu-kvm-9999 spice USE flag request

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Andreis Vinogradovs ( slepnoga ) 2010-08-10 21:46:53 UTC]

Please add USE flag spice in app-emulation/qemu-kvm-9999.
For more info, please see:
http://lists.gnu.org/archive/html/qemu-devel/2010-04/msg00967.html
http://www.linux-kvm.com/content/spice-support-added-upstream-qemu
http://cgit.freedesktop.org/spice/qemu/

and attached ebuild

[Comment 1 Andreis Vinogradovs ( slepnoga ) 2010-08-10 21:47:26 UTC]

Created attachment 242325 [details]
qemu-kvm-9999.ebuild witch USE spice

[Comment 2 Andreis Vinogradovs ( slepnoga ) 2010-08-10 21:49:31 UTC]

Created attachment 242327 [details]
qemu-kvm-9999_spice.diff diff for my ebuild

[Comment 3 Tiziano Müller (RETIRED) 2010-08-11 16:28:39 UTC]

hmm, not sure what the right solution would be here.
I created a separate ebuild, but it is a straight copy&paste from the qemu-kvm stuff.

[Comment 4 Tiziano Müller (RETIRED) 2010-08-11 16:31:17 UTC]

@qemu-people: what's your opinion here?

[Comment 5 Doug Goldstein (RETIRED) 2010-08-11 16:43:55 UTC]

While the -9999 ebuild isn't supported at all. I would say its totally a hack to completely change upstream for the -9999 ebuild to a third party repo. Wait for it to be merged by upstream.

The ebuild literally references git repos that have been submitted to upstream for review.

[Comment 6 Jorge Manuel B. S. Vicetto (RETIRED) 2010-08-11 16:59:07 UTC]

I agree with Doug that we should wait for the patches to be reviewed and accepted or rejected by upstream.

[Comment 7 Luca Barbato 2010-08-11 18:50:22 UTC]

I'd rather not have a third fork (qemu-kvm being the second) around. So I'd wait for it to merge properly...

[Comment 8 Tiziano Müller (RETIRED) 2010-08-12 07:35:20 UTC]

well, in that case I'm going to add a new ebuild qemu-kvm-spice (which I already prepared in my overlay) until things get merged. I need the stuff...
I'll probably also touch libvirt to make it accept the new ebuild as an alternative to qemu-kvm.
This way we'll also be able to track when upstream (qemu-kvm-spice upstream) rebases to a new head on the qemu-kvm git.

[Comment 9 Tiziano Müller (RETIRED) 2010-08-12 08:56:38 UTC]

Done. Ebuild is available as app-emulation/qemu-kvm-spice.

[Comment 10 Luca Barbato 2010-08-12 13:39:50 UTC]

That's exactly what I did not want...

[Comment 11 Doug Goldstein (RETIRED) 2010-08-12 14:31:00 UTC]

And I as well.

I'm going to be EXTREMELY clear here. qemu-kvm upstream will not support that branch at all. Similar to how qemu upstream doesn't support qemu-kvm's branches. A bunch of the work of the SPICE guys has been rejected by upstream until they complete their API/ABI break of their protocol that they have planned. libvirt won't support anything SPICE related until its merged upstream. I in turn will auto-close any bugs reported with qemu-kvm-spice and any related project (libvirt, virt-manager, etc).

This belongs in your dev overlay NOT in the tree.

[Comment 12 Tiziano Müller (RETIRED) 2010-08-12 15:04:38 UTC]

(In reply to comment #11)
> And I as well.
> 
> I'm going to be EXTREMELY clear here. qemu-kvm upstream will not support that
> branch at all.
> Similar to how qemu upstream doesn't support qemu-kvm's
> branches. A bunch of the work of the SPICE guys has been rejected by upstream
> until they complete their API/ABI break of their protocol that they have
> planned.
Which is almost over. spice-0.5.3 defines the stable api, final 0.6 should be released soon.

> libvirt won't support anything SPICE related until its merged
> upstream.
Libvirt accepts qemu-kvm-spice as a dependency for qemu now, that's all what's needed.

> I in turn will auto-close any bugs reported with qemu-kvm-spice
I maintain qemu-kvm-spice

> any related project (libvirt, virt-manager, etc).
fair enough