(In reply to Zeeshan Ali from comment #0)
> I think spice-guest-tools should also install qemu guest agent.

Why?

(In reply to Victor Toso from comment #1)
> (In reply to Zeeshan Ali from comment #0)
> > I think spice-guest-tools should also install qemu guest agent.
> 
> Why?

So that users don't have to fetch two different binaries from two different sources? Most (if not all) users who'd want spice-vdagent on the guest, would very likely also want qemu agent installed.

(In reply to Zeeshan Ali from comment #2) 
> So that users don't have to fetch two different binaries from two different
> sources? Most (if not all) users who'd want spice-vdagent on the guest,
> would very likely also want qemu agent installed.

From my point of view, spice-guest-tools are tools related to spice. For instance, It make sense to include the webdav daemon for shared folders which is an upstream feature.

Correct me if I'm mistaken but I don't see qemu-ga integrated with spice.

(In reply to Victor Toso from comment #3)
> (In reply to Zeeshan Ali from comment #2) 
> > So that users don't have to fetch two different binaries from two different
> > sources? Most (if not all) users who'd want spice-vdagent on the guest,
> > would very likely also want qemu agent installed.
> 
> From my point of view, spice-guest-tools are tools related to spice. For
> instance, It make sense to include the webdav daemon for shared folders
> which is an upstream feature.

If we are being very strict about names, yeah sure but I think we should strive to make user's lives easier even when that sometimes means not being very strict about names and definitions.

Not sure if oVirt agent really belongs in this binary either but AFAIK it was recently included.

(In reply to Zeeshan Ali from comment #4)
> (In reply to Victor Toso from comment #3)
> > (In reply to Zeeshan Ali from comment #2) 
> > > So that users don't have to fetch two different binaries from two different
> > > sources? Most (if not all) users who'd want spice-vdagent on the guest,
> > > would very likely also want qemu agent installed.
> > 
> > From my point of view, spice-guest-tools are tools related to spice. For
> > instance, It make sense to include the webdav daemon for shared folders
> > which is an upstream feature.
> 
> If we are being very strict about names, yeah sure but I think we should
> strive to make user's lives easier even when that sometimes means not being
> very strict about names and definitions.
> 
> Not sure if oVirt agent really belongs in this binary either but AFAIK it
> was recently included.

Also, not all virtio drivers installed by this binary are related to spice either, are they?

> If we are being very strict about names, yeah sure but I think we should
> strive to make user's lives easier even when that sometimes means not being
> very strict about names and definitions.

Not really about name but the fact that we use it or not.
The fact that we don't use it means that we are shipping something in our installer that it is useful for other applications, not spice.

I just want that to be very clear.

(In reply to Zeeshan Ali from comment #4)
> Not sure if oVirt agent really belongs in this binary either but AFAIK it
> was recently included.

Not exactly, it's included if you pass special build options, but not by default (and is not going to be present in the binaries shipped on spice-space.org)

I actually have the same question as Victor, what benefits are you/users going to get from this agent?

(In reply to Christophe Fergeau from comment #7)
> (In reply to Zeeshan Ali from comment #4)
> > Not sure if oVirt agent really belongs in this binary either but AFAIK it
> > was recently included.
> 
> Not exactly, it's included if you pass special build options, but not by
> default (and is not going to be present in the binaries shipped on
> spice-space.org)

Ah ok.

> I actually have the same question as Victor, what benefits are you/users
> going to get from this agent?

Well for one, Boxes will be able to sync the time of guest on restoration from a saved state.

So what's the verdict here? If spice-guest-tools won't install it, i'll have to dig into windows scripts of libosinfo to get it installed i guess.

Actually http://cgit.freedesktop.org/spice/spice-nsis/commit/?id=d970aaf06a0eefef7eeea0fff51635089a869050 .. even though it would be better to directly copy the agent binary ourselves I think.

(In reply to Christophe Fergeau from comment #10)
> Actually
> http://cgit.freedesktop.org/spice/spice-nsis/commit/
> ?id=d970aaf06a0eefef7eeea0fff51635089a869050 .. even though it would be
> better to directly copy the agent binary ourselves I think.

Cool! Thanks.

(In reply to Christophe Fergeau from comment #10)
> Actually
> http://cgit.freedesktop.org/spice/spice-nsis/commit/
> ?id=d970aaf06a0eefef7eeea0fff51635089a869050 .. even though it would be
> better to directly copy the agent binary ourselves I think.

Just confirming that we have qemu-ga enable upstream and we will ship it in the next upstream release of spice-guest-tools?

(In reply to Victor Toso from comment #12)
> Just confirming that we have qemu-ga enable upstream and we will ship it in
> the next upstream release of spice-guest-tools?

If I remember to test this to be sure it works, yes, should be there. Otherwise it might be there but non-working /o\

(In reply to Christophe Fergeau from comment #13)
> (In reply to Victor Toso from comment #12)
> > Just confirming that we have qemu-ga enable upstream and we will ship it in
> > the next upstream release of spice-guest-tools?
> 
> If I remember to test this to be sure it works, yes, should be there.
> Otherwise it might be there but non-working /o\

I'm closing this then.