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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 [email protected] http://lists.freedesktop.org/mailman/listinfo/spice-devel
