Re: [Spice-devel] [PATCH spice-protocol] build-sys: simplify autogen
On Fri, Dec 05, 2014 at 07:18:50PM +0100, Marc-André Lureau wrote: Where did you see that all patches have to be mandatorily reviewed in Spice? We always had a trivial push rule, and you always complained about it. That's all I know. What I remember from my first few years in SPICE was that all patches were going to the mailing lists before push. I don't remember any patch being pushed without prior review. Then it was implicitly agreed that a trivial push rule would not hurt, and I started complaining about some dubious patches you pushed abusing that rule. I don't remember complaining about anyone else's patch, nor seeing a lot of trivial pushes from anyone else (I've done a few myself, most of the time one liners or so). Christophe pgpZnVPHbePHD.pgp Description: PGP signature ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [spice-common 04/13] build-sys: Move smartcard check to m4 macro
On Fri, Dec 05, 2014 at 03:49:55PM -0600, Jonathon Jongsma wrote: I don't have strong opinions on moving these checks into macros (or the following patches that extract additional macros), but - Do they really need to all be in their own files? From a readability point of view, I think it's nicer to be able to browse all of these macros at once rather than opening a separate file to inspect each one Oh I can merge them in a single file, there are no particular reason why they are separate - In general, it'd be nice if the m4 macros had their arguments documented in a comment at the top of the macro. Then you don't have to read the whole implementation to find out how to use them. Ok, I'll add that. Christophe pgpG3JvDBiRDQ.pgp Description: PGP signature ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-protocol] build-sys: simplify autogen
On 12/06/2014 04:04 AM, Fabiano Fidêncio wrote: On Fri, Dec 5, 2014 at 11:08 PM, Marc-André Lureau wrote: On Fri, Dec 5, 2014 at 10:38 PM, Jonathon Jongsma wrote: For what it's worth, I basically agree with Christophe and Jeremy. I agree with Marc-André here. I too agree with Marc-Andre about _trivial_ patches (such as typo fixing). For any non-trivial patch, a review should be performed. Just to finish, IMHO, this patch, specifically, was not a trivial one. The problem here is that trivial is subjective. I view this specific patch as not trivial, as it practically replaces the whole file. I understand why Marc-Andre thinks it is trivial as the result of it is a common autogen.sh. Thanks, Uri. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-protocol] build-sys: simplify autogen
On 12/05/2014 05:52 PM, Marc-André Lureau wrote: On Fri, Dec 5, 2014 at 4:12 PM, Christophe Fergeau cferg...@redhat.com wrote: On Fri, Dec 05, 2014 at 03:57:29PM +0100, Marc-André Lureau wrote: The blame will be anyway on the one who typed it forever. I have absolutely no interest in blaming people after the fact, I prefer to fix things before the mistake happens ;) By that I mean that they are aware of the responsability of doing unreview commit. Nothing like replacing a crufted autogen with an obvious autoreconf. Is this what you did? This is not what I read in the commit log. Use autoreconf, allow out of tree autogen.sh run. Quick for me is a matter of minutes. Even if it's a few hours, or a few days, is it a big deal? That's a big factor, yes. There are a lot of trivial patches that have been pending for days. This means we need to improve on reviews :) Any pointers? I can point you to patches, but you should try to remember your own for a start. Also, you can see that other projects have troubles with that, ex http://wiki.qemu.org/Contribute/TrivialPatches: they are moving the problem to me, but perhaps it helps. Note that those trivial patches are being reviewed by the trivial patches team Improving the change can be done immediately upstream or by a after-commit review. That's not a valid argument. With pre-commit review, you ensure that at least one person read the patch. With post-commit review, you have no such guarantee. With current workflow, you have no guaratee that unreviewed patch go there by mistake or maliciously. We would need a tool for that. For me this is the job of maintainer to quickly review each commit before release. I disagree. When doing a release, a maintainer should _not_ review all commits. Those commits should have been reviewed before being committed. The number of patches added since the previous release can be large, and re-reviewing all of them can be too much work for little gain. Regards, Uri. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-protocol] build-sys: simplify autogen
On Mon, Dec 8, 2014 at 1:47 PM, Uri Lublin u...@redhat.com wrote: With current workflow, you have no guaratee that unreviewed patch go there by mistake or maliciously. We would need a tool for that. For me this is the job of maintainer to quickly review each commit before release. I disagree. When doing a release, a maintainer should _not_ review all commits. Those commits should have been reviewed before being committed. The number of patches added since the previous release can be large, and re-reviewing all of them can be too much work for little gain. This contradicts a bit the fact that you can do commit without review. I said quickly, doing thorough review of all commits before a release is not doable. But it is the role of the maintainer to check all the commits that go in a repository, because we don't have ways to enforce that all patches are the one that are ack on ML. (and I don't think we need that, to me the process works well so far) -- Marc-André Lureau ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-protocol] build-sys: simplify autogen
On Mon, Dec 08, 2014 at 01:53:43PM +0100, Marc-André Lureau wrote: This contradicts a bit the fact that you can do commit without review. I said quickly, doing thorough review of all commits before a release is not doable. But it is the role of the maintainer to check all the commits that go in a repository, because we don't have ways to enforce that all patches are the one that are ack on ML. (and I don't think we need that, to me the process works well so far) If you send all patches to spice-devel either for ACKing, or as a notice that you pushed a patch as trivial, then this kind of commits can be caught through spice-commits@ Then maybe the person doing the release won't trust people with commit access to commit the patches that were ACKed unmodified, which is another can of worms ;) Christophe pgpHv2SkVfW5w.pgp Description: PGP signature ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH RFC] Add HACKING file
This is libvirt's HACKING file with some parts not relevant to SPICE removed. It contains some git advice, some C coding style rules, and an attempt at defining what a trivial patch is. --- Hey, After the latest thread about trivial patches, I realized that libvirt actually has a definition of what patches can be pushed without review in their HACKING file. As it would be useful for us to have an agreed on definition for that, I went ahead and created a HACKING file. As the libvirt file had more useful bits, I tried to keep those as well (and also removed quite a bit of stuff). Christophe HACKING | 394 Makefile.am | 1 + 2 files changed, 395 insertions(+) create mode 100644 HACKING diff --git a/HACKING b/HACKING new file mode 100644 index 000..2a18038 --- /dev/null +++ b/HACKING @@ -0,0 +1,394 @@ + Contributor guidelines + == + + + +General tips for contributing patches += +(1) Discuss any large changes on the mailing list first. Post patches early and +listen to feedback. + + + +(2) Official upstream repository is kept in git (http://cgit.freedesktop.org/spice/spice/;) +and is browsable along with other SPICE-related repositories (e.g. +spice-protocol) online http://cgit.freedesktop.org/spice/. + + + +(3) Post patches in unified diff format, with git rename detection enabled. You +need a one-time setup of: + + git config diff.renames true + +After that, a command similar to this should work: + + diff -urp spice.orig/ spice.modified/ spice-myfeature.patch + +or: + + git diff spice-myfeature.patch + +Also, for code motion patches, you may find that git diff --patience +provides an easier-to-read patch. However, the usual workflow of spice +developer is: + + git checkout master + git pull + git checkout -t origin -b workbranch + Hack, committing any changes along the way + +When you want to post your patches: + + git pull --rebase + (fix any conflicts) + git send-email --cover-letter --no-chain-reply-to --annotate \ + --to=spice-devel@lists.freedesktop.org master + +(Note that the git send-email subcommand may not be in the main git package +and using it may require installation of a separate package, for example the +git-email package in Fedora.) For a single patch you can omit +--cover-letter, but a series of two or more patches needs a cover letter. If +you get tired of typing --to=spice-devel@lists.freedesktop.org designation you can set +it in git config: + + git config sendemail.to spice-devel@lists.freedesktop.org + +Please follow this as close as you can, especially the rebase and git +send-email part, as it makes life easier for other developers to review your +patch set. One should avoid sending patches as attachments, but rather send +them in email body along with commit message. If a developer is sending +another version of the patch (e.g. to address review comments), they are advised +to note differences to previous versions after the --- line in the patch so +that it helps reviewers but doesn't become part of git history. Moreover, such +patch needs to be prefixed correctly with --subject-prefix=PATCHv2 appended +to git send-email (substitute v2 with the correct version if needed +though). + + + +(4) In your commit message, make the summary line reasonably short (60 characters +is typical), followed by a blank line, followed by any longer description of +why your patch makes sense. If the patch fixes a regression, and you know what +commit introduced the problem, mentioning that is useful. If the patch +resolves a bugzilla report, mentioning the URL of the bug number is useful; +but also summarize the issue rather than making all readers follow the link. +You can use 'git shortlog -30' to get an idea of typical summary lines. +SPICE does not currently attach any meaning to Signed-off-by: lines, so it +is up to you if you want to include or omit them in the commit message. + + + +(5) Split large changes into a series of smaller patches, self-contained if +possible, with an explanation of each patch and an explanation of how the +sequence of patches fits together. Moreover, please keep in mind that it's +required to be able to compile cleanly after each patch. A feature does not +have to work until the end of a series, but intermediate patches must compile +and not cause test-suite failures (this is to preserve the usefulness of git +bisect, among other things). + + + +(6) Make sure your patches apply against SPICE GIT. Developers only follow GIT +and don't care much about released versions. + + + +There is more on this subject, including lots of links to background reading +on the subject, on Richard Jones' guide to working with open source projects +http://people.redhat.com/rjones/how-to-supply-code-to-open-source-projects/. + + +Code indentation + +SPICE's C
Re: [Spice-devel] [PATCH spice-protocol] build-sys: simplify autogen
On 12/08/2014 02:53 PM, Marc-André Lureau wrote: On Mon, Dec 8, 2014 at 1:47 PM, Uri Lublin u...@redhat.com wrote: With current workflow, you have no guaratee that unreviewed patch go there by mistake or maliciously. We would need a tool for that. For me this is the job of maintainer to quickly review each commit before release. I disagree. When doing a release, a maintainer should _not_ review all commits. Those commits should have been reviewed before being committed. The number of patches added since the previous release can be large, and re-reviewing all of them can be too much work for little gain. This contradicts a bit the fact that you can do commit without review. I said quickly, doing thorough review of all commits before a release is not doable. But it is the role of the maintainer to check all the commits that go in a repository, because we don't have ways to enforce that all patches are the one that are ack on ML. (and I don't think we need that, to me the process works well so far) OK. I agree that a maintainer should quick review the patches. At least to know what's new in the release and update some files (e.g. NEWS). Hopefully the maintainer would catch bad commits, pushed by mistake. (Let's (naively?) assume no malicious commits are pushed). That does not happen often (or at least not enough data about bad-commits is available). A maintainer can push a commit without review, but one should not for most patches. And those trivial patches, by definition, do not need to get reviewed by the maintainer doing the release. Uri ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH RFC] Add HACKING file
On Mon, Dec 08, 2014 at 03:37:32PM +0100, Marc-André Lureau wrote: So much of this is quite irrelevant to the discussion at hand about unreviewed commit rule. I know this is about a lot of stuff, libvirt HACKING fine had plenty of interesting things, so I thought why not keep them. I don't mind dropping everything :) In general I don't think we need that document, because we follow very common participation rules. Having strict rules makes contributions more difficult and that's really not what we are after at this point. It's more about having things documented in a place easy to refer to than about having strict rules, but I don't feel too strongly about having this in a HACKING file or not. you removed some part related to make check, I am not sure why. We don't have a decent make check, I'm not sure it's giving useful results. I can readd it. About unreview commit, this is a good summary of what we already apply. Bu the problem will remain that deciding whether a change trivial is subjective. I beleive my autogen.sh fix was obvious and fixed an obvious build problem and didn't required all this fuss. Many other parts of Spice would deserve that attention, not an autogen.sh fix. Yup, it is subjective, which is why it's good to have 'rule of thumb' rules which everyone agrees on. When a patch deviates too much from these rules, you know you should send it even though in your subjective opinion it's trivial. Regarding that recent patch (emphasis added): « **if a recently committed patch** breaks compilation on a platform or for a given driver, then it's fine to commit a **minimal** fix directly without getting the review feedback first » so it does not qualify even if you gut instinct told you otherwise. Christophe pgp9NRQ65b5Jt.pgp Description: PGP signature ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH RFC] Add HACKING file
On Mon, Dec 08, 2014 at 04:34:18PM +0100, Marc-André Lureau wrote: On Mon, Dec 8, 2014 at 4:25 PM, Christophe Fergeau cferg...@redhat.com wrote: « **if a recently committed patch** breaks compilation on a platform or for a given driver, then it's fine to commit a **minimal** fix directly without getting the review feedback first » What is minimal? The resulting file is a dozen lines long and idiomatic. A minimal fix is one with the smallest diffstat possible. autogen.sh | 167 ++ 1 file changed, 10 insertions(+), 157 deletions(-) I don't think you needed to change 167 lines just to fix out-of-tree autogen.sh. What does recently mean? What if something never worked in the first place? Recently would be in the last few hours/days. If something never worked, then it's not an urgent fix and should be sent for review. We can always add more strict and more defined rules, but the better will often be the enemy of the good. And it will remain subjective in the end. Well, in this case, most people in this thread agreed the patch was not trivial. Since you felt differently about it and thought it was eligible to being pushed without review, I think these rules should give some guidelines in the future about what should be fine to push, and what is going to cause another complaint on spice-devel. I don't think anyone will complain for patches with a diffstat with less than 5 lines changed which match the criteria in that HACKING file. Just send everything else to the mailing list for review, and everything will be fine. Christophe pgp8EfgdZMowl.pgp Description: PGP signature ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-protocol] build-sys: simplify autogen
On Sat, 2014-12-06 at 00:14 +0200, Alon Levy wrote: On 12/06/2014 12:00 AM, Jonathon Jongsma wrote: On Fri, 2014-12-05 at 23:41 +0200, Alon Levy wrote: [snip] At the same time, I'm not sure mailing lists are the right tool for code review. It's difficult to track which patches have been reviewed and which haven't. http://patchwork.freedesktop.org/project/Spice/list/ can help, linked from the wiki btw (http://www.spice-space.org/page/Main_Page) (not getting into this otherwise :) Thanks, I had forgotten about that. I notice now that all patches listed on that site are in state New. Is there a magical incantation we can insert into our review that will change the patch state to Approved or Needs Work or something? If so, can we start using this incantation rather than our traditional ACK, so that patchwork will be able to track the true state of these patches? I don't know that magic, but it does sound handy. Hrm, after trawling the patchwork mailing list archives, it appears that it's not actually possible to change the patch state via email. The authors consider this to be insecure since anybody could change the review state: https://lists.ozlabs.org/pipermail/patchwork/2012-April/000700.html That's too bad since I think it makes it significantly less useful as a passive tool for tracking patches. However we could at least set up the provided git post-receive hook that sets a patch status to Accepted after it is pushed to the repository. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH RFC] Add HACKING file
goes to 2 lists for post-review, and I would prefer people stick to technical conversations rather than community guidelines when there is no need for it and it doesn't noticeably improve the project for the rest of the people outside this very tiny contributor community. Now this is a place where I do have some standing, as a non Red Hat contributor. And *I* value this enormously. I would very much like to have these guidelines more clearly articulated. Now perhaps a HACKING file is not the best place for it, but it's not like the web site is a shining beacon... Cheers, Jeremy ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH RFC] Add HACKING file
On Mon, Dec 08, 2014 at 04:25:24PM +0100, Christophe Fergeau wrote: On Mon, Dec 08, 2014 at 03:37:32PM +0100, Marc-André Lureau wrote: So much of this is quite irrelevant to the discussion at hand about unreviewed commit rule. I know this is about a lot of stuff, libvirt HACKING fine had plenty of interesting things, so I thought why not keep them. I don't mind dropping everything :) In general I don't think we need that document, because we follow very common participation rules. Having strict rules makes contributions more difficult and that's really not what we are after at this point. It's more about having things documented in a place easy to refer to than about having strict rules, but I don't feel too strongly about having this in a HACKING file or not. Note that the title of the libvirt HACKING document says Contributor guidelines not Contributor rules They were not intended to be 100% strict rules that must be followed on pain of death at all times. They're intended to lay out the common case so that people have their broad expectations set at the right level, still leave contributors/reviewers the freedom to deviate if appropriate in particular patches/scenarios. FWIW, we've found the HACKING file rules very useful in getting new contributors onboard up to speed with the projects way of working. Long term contributors will of course have mentally interned all the knowledge from the doc long ago Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-protocol] build-sys: simplify autogen
Hey, On Mon, Dec 08, 2014 at 10:06:13AM -0600, Jonathon Jongsma wrote: Hrm, after trawling the patchwork mailing list archives, it appears that it's not actually possible to change the patch state via email. The authors consider this to be insecure since anybody could change the review state: https://lists.ozlabs.org/pipermail/patchwork/2012-April/000700.html That's too bad since I think it makes it significantly less useful as a passive tool for tracking patches. However we could at least set up the provided git post-receive hook that sets a patch status to Accepted after it is pushed to the repository. For what it's worth, Daniel Veillard hacked on patchchecker at some point for libvirt patch tracking: https://www.redhat.com/archives/libvir-list/2011-June/msg00418.html http://libvirt.org/git/?p=patchchecker.git;a=summary Christophe pgpqBj5p2Mu0X.pgp Description: PGP signature ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-protocol] build-sys: simplify autogen
On Fri, 2014-12-05 at 23:08 +0100, Marc-André Lureau wrote: On Fri, Dec 5, 2014 at 10:38 PM, Jonathon Jongsma jjong...@redhat.com wrote: For what it's worth, I basically agree with Christophe and Jeremy. (Although I think that describing it as mandatory code review is over-stating the case a bit -- there is nothing but peer pressure and polite requests preventing contributors from pushing unreviewed code). Peer pressure is precisely what one should try to avoid. If you think your change does not require second look, because it is trivial, then why would you do it? Now you will have to bother others repeatedly for the most basic thing that they might not even care about. I would rather work differently as I explained before, and as we did until now. By peer pressure, I simply mean the expectations that are shared by contributors of the project. And I think that some set of shared expectations are essential in a well-functioning project. So I disagree that peer pressure is something that should always be avoided. If somebody violates the shared expectations of the project, there *should* be some pressure to either stop violating those expectations, or re-negotiate a new set of shared expectations. Which is basically what we're doing now, right? Jonathon ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH][spice-gtk] build-sys: make path to polkit consider prefix.
Hi
- Original Message -
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index b55f3a0..c150e2f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -449,7 +449,7 @@ if test x$have_usbredir = xyes test
x$enable_polkit != xno; then
AC_DEFINE([USE_POLKIT], [1], [Define if supporting polkit])
fi
AM_CONDITIONAL([WITH_POLKIT], [test x$have_polkit = xyes])
- POLICYDIR=`${PKG_CONFIG} polkit-gobject-1 --variable=policydir`
+ POLICYDIR=${prefix}/`${PKG_CONFIG} polkit-gobject-1
--variable=policydir`
Hmm, is this going to work?
$ pkg-config polkit-gobject-1 --variable=policydir
/usr/share/polkit-1/actions/
Prepending /usr isn't good.
If you want to install out of prefix, you should consider DESTDIR=/tmp/foo make
install
AC_SUBST(POLICYDIR)
# Check for polkit_authority_get_sync()
AC_CHECK_LIB([polkit-gobject-1], [polkit_authority_get_sync],
ac_have_pk_auth_get_sync=1, ac_have_pk_auth_get_sync=0)
--
2.1.0
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH][spice-gtk] build-sys: make path to polkit consider prefix.
Hey, Hmm, is this going to work? $ pkg-config polkit-gobject-1 --variable=policydir /usr/share/polkit-1/actions/ Prepending /usr isn't good. If you want to install out of prefix, you should consider DESTDIR=/tmp/foo make install I usually install it in may $HOME/dev, yes. The problem with DESTDIR is with the pkg-config files. I would compile it without the prefix so the pkg-config files would have the default prefix set (prefix=/usr/local) installed in another place due to DESTDIR=... I could sed them all to fix it but isn't it a problem to set the --prefix and having a file being installed somewhere else of that prefix? Regards, Victor Toso ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH][spice-gtk] build-sys: make path to polkit consider prefix.
On Mon, Dec 8, 2014 at 8:43 PM, Victor Toso victort...@redhat.com wrote: I usually install it in may $HOME/dev, yes. The problem with DESTDIR is with the pkg-config files. I would compile it without the prefix so the pkg-config files would have the default prefix set (prefix=/usr/local) installed in another place due to DESTDIR=... Sorry, I don't follow :) I could sed them all to fix it but isn't it a problem to set the --prefix and having a file being installed somewhere else of that prefix? It is not really. I think you should simply disable policykit here, the policy can't be read from your own $prefix here. -- Marc-André Lureau ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] spice-xpi client fails to run
Hi, I have a RHEV 3.3 environment but I run 3.17.4-1-ARCH on my work station and would like to access the RHEV spice server on the VM's, I have also tried with openSuSE but I never get the expected Spice window frame that I would get if I used a RHEL system with the spice-xpi. The spice frame has other options for the VM, e.g. usb options. As seen in the below link: http://tinyurl.com/kwpqm8y I suspect this is due to the below that I have found in my logs: Dec 08 08:59:57 linux-rocks firefox.desktop[1378]: (plugin-container:1473): SpiceXPI-CRITICAL **: controller connect: No such file or directoryDec 08 08:59:57 linux-rocks firefox.desktop[1378]: SpiceXPI-Message: failed to run spice-xpi-client, running spicec instead How can I get my system to run the xpi client instead of using spicec? I am using firefox 34.0.5 Let me know if any other info is needed? -Alex ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
