[Spice-devel] Spice agent and LXC
Charles Ricketts
githlar at gmail.com
Mon Dec 1 03:24:43 PST 2014
The actual commit that made this change is here:
http://cgit.freedesktop.org/spice/spice-protocol/commit/spice/vd_agent.h?id=5ff3fa7080bd08392fc011175657264d57dddcec.
It's about a year old and if I'm reading the tags correctly in the
.../spice/spice repository, 0.8.0 was released March 2012. So, as far as I
can tell it would correlate. However, if you still want me to file the bug
I can do it. Though, honestly, I have a feeling that it'd get marked "Not a
bug" pretty quickly given that passing the version-matched library via
LD_LIBRARY_PATH or ldconfig works as expected.
Charles R.
On Mon, Dec 1, 2014 at 5:07 AM, Charles Ricketts <githlar at gmail.com> wrote:
> I just did a verification and the symbol was actually
> VD_AGENT_MAX_CLIPBOARD, not that it matters all that much but perhaps
> you'll know what this is and won't have to look it up and dig through git
> or anything ;).
>
> By the way, tarball sources were mentioned as being more manageable in
> general. As a matter of practicality, should spice sources be compiled from
> the tarballs or git? Or does it matter? FWIW, I don't know a whole lot
> about git, just how to 'git clone', but I always imagined that doing so
> would pull in every change up until the point it's done, regardless of
> whether it's actually made it into a release or not and might break things
> depending on when it's done. Generally speaking, is this a relevant concern?
>
> Also, I suppose I'll provide a status update: I did manage to get QXL
> working with GDM in Fedora 20. Ubuntu 14.04, however, is causing me
> headaches. Due to a combination of its limited implementation of systemd
> and/or the fact that I'm running it within an LXC container breaks the
> systemd cgroup, preventing vdagentd from getting session information from
> vdagent and therefore preventing it from working properly. And, since
> ConsoleKit auth has been dropped in 14.04, that's out of the question as
> well. Even if I were to install the Pam module, apparently using them both
> in combination is frowned upon if not impossible and prone to breakage.
> Nevertheless, I've moved my further questions to the Ubuntu and LXC guys
> since I'm unsure exactly which system is causing the problem, but it's
> clearly not Spice-related.
>
> However, one thing that may be Spice related is the tendency for the LXC
> display to hang. For example, when GDM starts in Fedora 20, it takes about
> a minute and a half or so to bring up the actual login display. At first I
> attributed this to Gnome Shell (I use it myself and know how slow it can be
> at times), but I found that this is actually a recurring problem when stuff
> moves on the screen repeatedly. One reproducible example I found was
> playing a YouTube video within Spice (not even full screen). It would cause
> the whole display to do the same hang for a long period of time as well.
> The display would hang until the video ended (or perhaps some time after, I
> didn't time it exactly) or until the Firefox close button was clicked and
> after a fairly long delay (30 seconds, maybe). I would like to investigate
> this as well, but I will need to figure out how to set up an alternate
> display for comparison in order to be able to determine whether it's
> actually Spice or not.
>
> Charles R.
>
> On Mon, Dec 1, 2014 at 4:33 AM, Charles Ricketts <githlar at gmail.com>
> wrote:
>
>> I'm pretty sure that is actually the case. I know that I got a
>> compilation error at first on Ubuntu because I had forgotten to install the
>> development headers from the git sources. Compiling against the 1.8.0
>> headers in the 14.04 repositories gave me an error related to either
>> VD_AGENT_CLIPBOARD_MAX_SIZE_DEFAULT or VD_AGENT_CLIPBOARD_MAX_SIZE_ENV, I
>> forget which exactly. This symbol is in
>> /usr/include/spice-1/spice/vd_agent.h. If I'm looking at this correctly,
>> wouldn't something like this cause the problem?
>>
>> In case I'm wrong, there is no debug spice-server library available on
>> Ubuntu 14.04 anyway. So, in order to compile one, would it be as easy as
>> `CFLAGS="$CFLAGS -g" make`, or something a little more intricate? I've done
>> simple compilations of programs I've written myself using `g++ -lm main.cpp
>> -o my_program,` but that's about the extent of it. I can usually get
>> configure scripts to work with me, but when it comes to Automake I'm
>> completely lost.
>>
>> Chuck R.
>>
>> On Mon, Dec 1, 2014 at 3:14 AM, Christophe Fergeau <cfergeau at redhat.com>
>> wrote:
>>
>>> On Sat, Nov 29, 2014 at 08:34:48PM -0600, Charles Ricketts wrote:
>>> > > Christophe
>>> > The segfault was simply a configuration error. it was dynamically
>>> > linking the distribution-provided libspice-server.so.1.8.0 rather than
>>> > the newly compiled libspice-server.so.1.9.0 due to the 1.8.0 version
>>> > having a higher precedence with ldconfig. After reordering the library
>>> > precedence to favor the new version it worked just fine.
>>>
>>> Unless the segfault was caused by a new symbol available in 1.9.0, but
>>> not present in 1.8.0, this should not be happening. This could be a bug
>>> in spice-server that was fixed in the new version, in which case it
>>> would be good that ubuntu is aware about it so that they can fix it in
>>> their package.
>>>
>>> Christophe
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20141201/598f6139/attachment-0001.html>
More information about the Spice-devel
mailing list