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.
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.
On Mon, Dec 1, 2014 at 4:33 AM, Charles Ricketts <githlar@xxxxxxxxx> wrote:
Chuck R.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.On Mon, Dec 1, 2014 at 3:14 AM, Christophe Fergeau <cfergeau@xxxxxxxxxx> 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
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel