[Spice-devel] Try to port spicec into Android
Shuxiang Lim
shohyanglim at gmail.com
Thu Mar 17 23:09:38 PDT 2011
Ok,my prediction is right, this segfault is solved by disabling NLS (the use
of gettext(). etc..)in glib.
Yet then Bus Error comes: I know,it's mainly caused by the typecast for ARM
has no same alignment style as x86.The question is: is there a way to fix
this in the arm-gcc option other than rewrite the typecast statements into
memcpy()?(There are huge amount of such statements in glib.). The -O0 option
doesnot work.
Rgrds.
On Fri, Mar 18, 2011 at 11:52 AM, Shuxiang Lim <shohyanglim at gmail.com>wrote:
> Hi,all,caution of the radioactive rays!
> I feel rather frustrated though...Now I have ported libglib2.0 and its
> deps(libintl,libiconv...) onto android as well as libspicec-glib.so and
> snappy.
> But when run,the snappy got only SEGFAULT and killed.
> *#LD_LIBRARY_PATH=/data/local/lib ./snappy -h 192.168.1.31 -p 5900 -o
> ahoo.ppm*
> *[1] + Stopped (signal) LD_LIBRARY_PATH=/data/local/lib ./snappy -h
> 192.168.1.31 -p 5900 -o ahoo.ppm
> [1] Segmentation fault LD_LIBRARY_PATH=/data/local/lib ./snappy -h
> 192.168.1.31 -p 5900 -o ahoo.ppm*
>
> Tracing the process,I found the SEGFAULT came from the
> glib:g_object_new()!:
> gtk/spice-session.c:
> addr = g_object_new (G_TYPE_NETWORK_ADDRESS, "hostname", s->host, "port",
> port, NULL);
> -->libgobject:gobject/gtype.c
> g_object_new()-->g_type_class_ref()-->type_class_init_Wm()
> -->libgio:gio/gnetworkaddress.c
> g_network_address_class_init()-->CRASSSSHHHH.
>
> Now I'm still tracing the bug... It may come from the i18n string ops, but
> if other bug occurs in glib,the future is dim... For I really has no time
> and energy to hack the arcane and exotic glib(or it's caused by the
> incorrect use of glib method in spicec?).(forgive such adjectives,to me,it's
> true)
> I really yearn for the spicec in PURE C and Modularized:
> 1.Offer the switch to disable (do not POSIX-likedly depend on) locale,
> libiconv, libintl, sys/shm.h, pwd.h, pthread,i18n, wchar_t,regex,gettext,...
> for none of them can be found in android!
> 2. Be as far away as we can from the other libs like the
> glib/gtk,pulseaudio/alsalib...
> 3. Completely modularize spicec into libspicec and spicec (this is what I
> am working for)
> as the data layer and the UI layer to ease the porting.
>
> Is there any plan about these now? Can anybody help to do the step 1 or
> step 2 above?
> Or, the simplest: the way to safely turn off locale and i18n in glib?
> Pardon my whining and wish me Goodluck!
> And again I shall desperately curse Android and bless Meego!
> Regards.
>
>
> On Thu, Mar 10, 2011 at 9:07 AM, Shuxiang Lim <shohyanglim at gmail.com>wrote:
>
>>
>> That's true. But the audio output as well as the image output is unexposed
>> or disabled for C/C++ apps in Android.So I plan to dwindle the work to
>> implement the image first,if success, the audio work will be easy to follow.
>>
>> Regards.
>>
>> On Wed, Mar 9, 2011 at 6:22 PM, Attila Sukosd <attila.sukosd at gmail.com>wrote:
>>
>>> Could you maybe give access to other devs to aid the development?
>>>
>>> Rgrds,
>>>
>>> Attila
>>>
>>>
>>> On Wed, Mar 9, 2011 at 11:18 AM, Shuxiang Lim <shohyanglim at gmail.com>wrote:
>>>
>>>> Yep, I walked around this but to face more chored and nasty troubles in
>>>> porting Pulseaudio lib, time limited, so I decided to DISABLE the
>>>> audio(playback/record) channels first. Thus the porting of libspicec_glib.so
>>>> is finished(along with all its dependences) and androidVNCViewer(whose UI
>>>> will be peeled to become spicec's) proj. has been built:
>>>> *#file libspicec_glib.so *
>>>> libspicec_glib.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV),
>>>> dynamically linked, not stripped
>>>> *#arm-eabi-readelf -d libspicec_glib.so *
>>>> Dynamic section at offset 0x774a4 contains 27 entries:
>>>> Tag Type Name/Value
>>>> 0x00000001 (NEEDED) Shared library: [libc.so]
>>>> 0x00000001 (NEEDED) Shared library: [libm.so]
>>>> 0x00000001 (NEEDED) Shared library:
>>>> [libpixman-1.so.0]
>>>> 0x00000001 (NEEDED) Shared library:
>>>> [libssl.so.1.0.0]
>>>> 0x00000001 (NEEDED) Shared library:
>>>> [libcrypto.so.1.0.0]
>>>> 0x00000001 (NEEDED) Shared library: [libjpeg.so.62]
>>>> 0x00000001 (NEEDED) Shared library: [libz.so]
>>>> 0x00000001 (NEEDED) Shared library:
>>>> [libglib-2.0.so.0]
>>>> 0x00000001 (NEEDED) Shared library:
>>>> [libgio-2.0.so.0]
>>>> 0x00000001 (NEEDED) Shared library:
>>>> [libgobject-2.0.so.0]
>>>> 0x00000001 (NEEDED) Shared library:
>>>> [libgmodule-2.0.so.0]
>>>> 0x00000001 (NEEDED) Shared library:
>>>> [libgthread-2.0.so.0]
>>>> 0x00000010 (SYMBOLIC) 0x0
>>>> ....
>>>> Now comes the last adventure of Native interfaces exposing and UI
>>>> building!
>>>> Regards.
>>>>
>>>>
>>>> On Wed, Mar 9, 2011 at 3:57 PM, Shuxiang Lim <shohyanglim at gmail.com>wrote:
>>>>
>>>>> Well, I think I may try the "--with-coroutine=gthread" in spice-gtk
>>>>> configuring to walk around that...
>>>>>
>>>>>
>>>>> On Wed, Mar 9, 2011 at 11:10 AM, Shuxiang Lim <shohyanglim at gmail.com>wrote:
>>>>>
>>>>>> Hi,I need help!
>>>>>> Now I've managed to divided spicec-gtk into two parts
>>>>>> libspicec.so(based on libpixman.so,libglib-2.0.so...No relation to X11 at
>>>>>> all) and spicec(based on libspicec.so and libgtk.so...). And the glib2.0
>>>>>> porting to Android is also completed. But I'm blocked in compiling libspicec
>>>>>> onto Android at the begining for the continuation.c uses the functions in
>>>>>> <ucontext.h> :setcontext(),getcontext()..., which are some thread-related
>>>>>> funcs as I know,and, definitely unsuprisingly, Android libc doesn't have
>>>>>> them! Is there a way to drop or replace the use of such funcs? Or should I
>>>>>> manually write setcontext from scratch?
>>>>>> RGRDs.
>>>>>>
>>>>>>
>>>>>> On Mon, Mar 7, 2011 at 5:14 PM, Alon Levy <alevy at redhat.com> wrote:
>>>>>>
>>>>>>> On Mon, Mar 07, 2011 at 09:08:28AM +0800, Shuxiang Lim wrote:
>>>>>>> > Option 1: use spice-gtk with a gtk android backend
>>>>>>> > a) compiling gtk for it would be possible.
>>>>>>> > b) write a partial gtk backend, good enough for spice-gtk.
>>>>>>> > c) no changes to spice-gtk.
>>>>>>> > Yep,that's really a good hope,but it's another project(too huge
>>>>>>> and far
>>>>>>> > away for me now):
>>>>>>> > Project:"GTK for Android.". So now I can use only the Android SDK
>>>>>>> to finish
>>>>>>> > the UI(the new native UI APIs in NDK is not reliable in versions).
>>>>>>>
>>>>>>> Yeah, I think you're right, I can't find anyone already working on
>>>>>>> this by
>>>>>>> simple web search. Maybe spice-gtk's non ui objects are dependent
>>>>>>> only on
>>>>>>> gobject / stuff that is easy to just drop in (ugly, but still more
>>>>>>> maintainable
>>>>>>> then basing your work on spicec, long term).
>>>>>>>
>>>>>>> > And also you've referred that "spicec is already platform
>>>>>>> independent",
>>>>>>> > that's true to Linux and Windows,but not to Android,for such
>>>>>>> independence is
>>>>>>> > based on the C++ independence over the os which cannot stand
>>>>>>> through the
>>>>>>> > JAVA UIed android.So there is no way to just add a subdir ./android
>>>>>>> under
>>>>>>> > spice/client along with ./x11 and ./windows. It should be a
>>>>>>> combined proj.
>>>>>>> > of C/C++ and Java. (That's why I hate Android and yearn for
>>>>>>> Maemo/Meego.)
>>>>>>>
>>>>>>> Definitely easier to port to Maemo :)
>>>>>>>
>>>>>>> > Regards.
>>>>>>> >
>>>>>>> > On Fri, Mar 4, 2011 at 7:04 PM, Alon Levy <alevy at redhat.com>
>>>>>>> wrote:
>>>>>>> >
>>>>>>> > > On Fri, Mar 04, 2011 at 06:21:19PM +0800, Shuxiang Lim wrote:
>>>>>>> > > > Hi, friends,
>>>>>>> > > > Thanks for your replies. It's definitely right till now
>>>>>>> I've been
>>>>>>> > > > working a tougher way compared to spice-gtk.And actually I've
>>>>>>> considered
>>>>>>> > > to
>>>>>>> > > > steer my way to the latter in fear of the troublesome and
>>>>>>> crippled C++
>>>>>>> > > > support in Android NDK:C is more "simple and safe" in Android
>>>>>>> than C++.
>>>>>>> > > > But,AFAIK,there is no gtk port for Android yet. And the biggest
>>>>>>> obstacle
>>>>>>> > > is
>>>>>>> > > > the framework of Android:in its design,all UI should be done in
>>>>>>> JAVA
>>>>>>> > > powered
>>>>>>> > > > by SKIA libs.Therefore the port of UI libs(GTK,etc) will be
>>>>>>> choked by the
>>>>>>> > > > I/O level because Android don't completely expose them at
>>>>>>> all!(I once
>>>>>>> > > > managed to port Xfbdev onto it,but that's not commercially
>>>>>>> practical at
>>>>>>> > > all,
>>>>>>> > > > it's just a geeky trick maybe,an app in Android SHOULD NOT do
>>>>>>> this.) Only
>>>>>>> > > > the algorithm/data computing-related C/C++ libs are welcomed to
>>>>>>> be the
>>>>>>> > > JNI
>>>>>>> > > > servants to JAVA UI apps in Android.
>>>>>>> > > > You see, in such aspect, there is not too much diff between
>>>>>>> the C++
>>>>>>> > > way
>>>>>>> > > > and gtk way in the porting of UI part.
>>>>>>> > >
>>>>>>> > > I'm going to try to prove that wrong by grepping hoping it makes
>>>>>>> sense, I
>>>>>>> > > never
>>>>>>> > > actually coded in gtk:
>>>>>>> > >
>>>>>>> > > $ git grep GObjectClass
>>>>>>> > > gtk/channel-cursor.c: GObjectClass *gobject_class =
>>>>>>> > > G_OBJECT_CLASS(klass);
>>>>>>> > > gtk/channel-display.c: GObjectClass *gobject_class =
>>>>>>> > > G_OBJECT_CLASS(klass);
>>>>>>> > > gtk/channel-inputs.c: GObjectClass *gobject_class =
>>>>>>> > > G_OBJECT_CLASS(klass);
>>>>>>> > > gtk/channel-main.c: GObjectClass *gobject_class =
>>>>>>> G_OBJECT_CLASS(klass);
>>>>>>> > > gtk/channel-playback.c: GObjectClass *gobject_class =
>>>>>>> > > G_OBJECT_CLASS(klass);
>>>>>>> > > gtk/channel-record.c: GObjectClass *gobject_class =
>>>>>>> > > G_OBJECT_CLASS(klass);
>>>>>>> > > gtk/spice-audio.h: GObjectClass parent_class;
>>>>>>> > > gtk/spice-channel.c: GObjectClass *gobject_class =
>>>>>>> G_OBJECT_CLASS
>>>>>>> > > (klass);
>>>>>>> > > gtk/spice-channel.h: GObjectClass parent_class;
>>>>>>> > > gtk/spice-gstaudio.c: GObjectClass *gobject_class =
>>>>>>> > > G_OBJECT_CLASS(klass);
>>>>>>> > > gtk/spice-pulse.c: GObjectClass *gobject_class =
>>>>>>> G_OBJECT_CLASS(klass);
>>>>>>> > > gtk/spice-session.c: GObjectClass *gobject_class =
>>>>>>> > > G_OBJECT_CLASS(klass);
>>>>>>> > > gtk/spice-session.h: GObjectClass parent_class;
>>>>>>> > > gtk/spice-widget.c: GObjectClass *gobject_class =
>>>>>>> G_OBJECT_CLASS(klass);
>>>>>>> > >
>>>>>>> > > otoh:
>>>>>>> > > U playa:spice-gtk alon (master)$ git grep --name-only GdkWindow
>>>>>>> > > gtk/spice-widget-cairo.c
>>>>>>> > > gtk/spice-widget.c
>>>>>>> > >
>>>>>>> > > (if you grep Window you get false negatives because of the
>>>>>>> compression
>>>>>>> > > window).
>>>>>>> > >
>>>>>>> > > Anyway, this is a lame attempt to prove the gtk stuff that does
>>>>>>> ui (read:
>>>>>>> > > uses X)
>>>>>>> > > is separated in the code/architecture level :)
>>>>>>> > >
>>>>>>> > > > So for me the shining light of spicec-gtk is not in "GTK"
>>>>>>> but in "C".
>>>>>>> > > I
>>>>>>> > > > dare not to say I'm clear about every nook in spicec at all. My
>>>>>>> best hope
>>>>>>> > > is
>>>>>>> > > > that the IO in spicec shall be straight and succinct ,the inner
>>>>>>> > > > graphic/sound computing(decompress,etc) shall have NO relation
>>>>>>> with upper
>>>>>>> > > UI
>>>>>>> > > > libs at all, so I can pipe the Finished image flow into UI
>>>>>>> through JNI
>>>>>>> > > > interfaces and direct the user input backward. (That's why I
>>>>>>> can borrow
>>>>>>> > > the
>>>>>>> > > > UI from AndroidVNCViewer)
>>>>>>> > >
>>>>>>> > > Yeah, I think it is generally so, but again, it's so in spice-gtk
>>>>>>> too, and
>>>>>>> > > that's
>>>>>>> > > our only future supported client (*).
>>>>>>> > >
>>>>>>> > > (*) plans do change.
>>>>>>> > > >
>>>>>>> > > > libspicec.so(do most jobs)
>>>>>>> > > > <==finishedimages/audio>>===<<inputs==>spicec.java.ui(only UI)
>>>>>>> > > >
>>>>>>> > > > Am I right? Is there any design that will frustrate this in
>>>>>>> spicec or
>>>>>>> > > > spice-gtk?
>>>>>>> > >
>>>>>>> > > spicec is already separated at the platform level, since it uses
>>>>>>> low level
>>>>>>> > > libraries directly, unlike spice-gtk (X and GDI). So you would
>>>>>>> basically
>>>>>>> > > be adding a platform/android.
>>>>>>> > >
>>>>>>> > > In gtk I really haven't done android development, ever, at least
>>>>>>> not in the
>>>>>>> > > C level, but I was hoping:
>>>>>>> > > Option 1: use spice-gtk with a gtk android backend
>>>>>>> > > a) compiling gtk for it would be possible.
>>>>>>> > > b) write a partial gtk backend, good enough for spice-gtk.
>>>>>>> > > c) no changes to spice-gtk.
>>>>>>> > >
>>>>>>> > > Option 2 is of course to make spice-gtk also have platform
>>>>>>> separation,
>>>>>>> > > while
>>>>>>> > > still using gtk/gobject for all stuff that would Just Work when
>>>>>>> doing 1.a
>>>>>>> > > (the
>>>>>>> > > data structures, the signals, the macros, the introspection?).
>>>>>>> > >
>>>>>>> > > > Regards.
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > > On Fri, Mar 4, 2011 at 4:36 PM, Alon Levy <alevy at redhat.com>
>>>>>>> wrote:
>>>>>>> > > >
>>>>>>> > > > > On Fri, Mar 04, 2011 at 03:38:51PM +0800, Shuxiang Lim wrote:
>>>>>>> > > > > > Hi all,
>>>>>>> > > > > > I'm trying these days to port spicec into Android.But
>>>>>>> it's a
>>>>>>> > > rather
>>>>>>> > > > > TOUGH
>>>>>>> > > > > > way to go because the structure of spicec and android are
>>>>>>> desperately
>>>>>>> > > > > > inappropriate:the linux version of spicec is based on the
>>>>>>> X11,which
>>>>>>> > > is
>>>>>>> > > > > not
>>>>>>> > > > > > available in Android,thus the UI of spicec should be
>>>>>>> rewritten from
>>>>>>> > > > > > scratch...More troublesome is that the UI part and data
>>>>>>> part in
>>>>>>> > > current
>>>>>>> > > > >
>>>>>>> > > > > Haven't looked at your proposal below yet, but did you check
>>>>>>> the
>>>>>>> > > spice-gtk
>>>>>>> > > > > work? maybe it is easier to start from that? are gtk
>>>>>>> libraries
>>>>>>> > > available on
>>>>>>> > > > > android? not talking about X. spice-gtk has objects for
>>>>>>> connection and
>>>>>>> > > > > channels
>>>>>>> > > > > that afaik don't do any output, that's separate from the
>>>>>>> actual widget
>>>>>>> > > that
>>>>>>> > > > > uses X. Also, gtk 3 has backends - did anyone do a backend
>>>>>>> for android?
>>>>>>> > > > >
>>>>>>> > > > > Since going forward we plan to ditch the spicec client, that
>>>>>>> would be
>>>>>>> > > > > really
>>>>>>> > > > > preffered. Now that I see what you have planned it sounds
>>>>>>> good, but
>>>>>>> > > better
>>>>>>> > > > > to use spice-gtk.
>>>>>>> > > > >
>>>>>>> > > > > of course that's not to say we won't love to see this working
>>>>>>> anyway :)
>>>>>>> > > > >
>>>>>>> > > > > > spicec is entangled in the hierarchical system in C++! So
>>>>>>> my plan is
>>>>>>> > > > > this:
>>>>>>> > > > > > first split the spicec into two parts,data and UI,transform
>>>>>>> the data
>>>>>>> > > part
>>>>>>> > > > > > into libspicec.so;then rewrite the UI part in JAVA.
>>>>>>> Besides, I should
>>>>>>> > > > > also
>>>>>>> > > > > > tinker some problems caused by the Crippled NDK C++ support
>>>>>>> and the
>>>>>>> > > Lamed
>>>>>>> > > > > > bionic c lib in android .
>>>>>>> > > > > > And now the first step is roughly done,hence the change
>>>>>>> of the
>>>>>>> > > spicec
>>>>>>> > > > > > structure:
>>>>>>> > > > > > From
>>>>>>> > > > > >
>>>>>>> > > |-->playback
>>>>>>> > > > > > thread
>>>>>>> > > > > >
>>>>>>> > > |-->cursor
>>>>>>> > > > > > thread
>>>>>>> > > > > > spicec:spicec process（application process）-->main
>>>>>>> thread->|-->*record
>>>>>>> > > > > thread
>>>>>>> > > > > > *
>>>>>>> > > > > >
>>>>>>> > > |-->inputs
>>>>>>> > > > > > thread
>>>>>>> > > > > >
>>>>>>> > > |-->display
>>>>>>> > > > > > thread
>>>>>>> > > > > > To:
>>>>>>> > > > > > ===========================>
>>>>>>> > > > > > |-->libspicec.so:application
>>>>>>> thread-->main
>>>>>>> > > > > > thread------>|
>>>>>>> > > > > > |
>>>>>>> > > > > > |
>>>>>>> > > > > > | |<--display
>>>>>>> thread<--|
>>>>>>> > > > > > |
>>>>>>> > > > > > | |--->|<--cursor
>>>>>>> > > > > > thread<---|<------------------|
>>>>>>> > > > > > | | |<--inputs
>>>>>>> thread<---|
>>>>>>> > > > > > spicec:spicec process--->| | |<--playback
>>>>>>> thread<-|
>>>>>>> > > > > > | |
>>>>>>> > > > > > | |
>>>>>>> > > > > > | |
>>>>>>> > > > > > <---------------------------------------------|
>>>>>>> > > > > > |
>>>>>>> > > > > > |
>>>>>>> > > > > > |
>>>>>>> > > > > > |
>>>>>>> > > > > > |-->spicec:platform
>>>>>>> > > > > > thread------------------------------>|
>>>>>>> > > > > >
>>>>>>> > > > > > The hierarchical relationship has been unleashed with one
>>>>>>> > > thread(record
>>>>>>> > > > > > channel) deleted and two new threads (app and platform)
>>>>>>> created. The
>>>>>>> > > > > first
>>>>>>> > > > > > as the "data thread",the other as the "work thread" which
>>>>>>> is driven
>>>>>>> > > by
>>>>>>> > > > > the
>>>>>>> > > > > > signals from the first thread as well as its sub threads
>>>>>>> and
>>>>>>> > > requested to
>>>>>>> > > > > do
>>>>>>> > > > > > the UI-related work:
>>>>>>> > > > > >
>>>>>>> > > > > > platform thread：------------>blocked and waiting:-->job
>>>>>>> > > > > > request-<--------------|
>>>>>>> > > > > > | |
>>>>>>> > > > > > |
>>>>>>> > > > > > ^ |
>>>>>>> > > > > > |
>>>>>>> > > > > > |
>>>>>>> > > > > > | |
>>>>>>> > > > > > |<----------|-<-|
>>>>>>> > > > > > |
>>>>>>> > > > > > | |
>>>>>>> > > > > > |
>>>>>>> > > > > > platform thread over<----------if(job==die)<--|
>>>>>>> send req.
>>>>>>> > > blocked
>>>>>>> > > > > > and waiting
>>>>>>> > > > > > | ^
>>>>>>> |
>>>>>>> > > > > > |
>>>>>>> > > > > > | |
>>>>>>> |
>>>>>>> > > > > > ^
>>>>>>> > > > > > | |
>>>>>>> |
>>>>>>> > > > > > _________|_________
>>>>>>> > > > > > | |
>>>>>>> |
>>>>>>> > > > > > | app/plbk/cusor
>>>>>>> > > > > > thd
>>>>>>> > > > > > |<---job done----dojob()<--else--| |
>>>>>>> |->go
>>>>>>> > > on->|
>>>>>>> > > > > > __________________
>>>>>>> > > > > > | |
>>>>>>> > > > > > |------------------------------->feed back-->|
>>>>>>> > > > > >
>>>>>>> > > > > >
>>>>>>> > > > > > So the next work is to expose the native JNI interface in
>>>>>>> platform
>>>>>>> > > thread
>>>>>>> > > > > to
>>>>>>> > > > > > the UI written in Android SDK. I try to use the UI
>>>>>>> > > > > > frame of AndroidVNCViewer in
>>>>>>> > > > > > code.google.com/p/*android*-*vnc*-viewer/,then the work of
>>>>>>> platform
>>>>>>> > > > > > thread will be replaced by UI but the msg
>>>>>>> > > > > > communication to libspicec will be remained. That's the
>>>>>>> easiest way I
>>>>>>> > > can
>>>>>>> > > > > > envisage except rewriting all parts in spicec from scratch.
>>>>>>> > > > > > It's tough too, for I have poor experiance in Java...
>>>>>>> > > > > > Anyway, is there any other guy working on this? Is my
>>>>>>> way
>>>>>>> > > > > feasible??Any
>>>>>>> > > > > > Ideas or help is appreciated.
>>>>>>> > > > >
>>>>>>> > > > > See above for ideas, don't read them as a criticism, I think
>>>>>>> this is
>>>>>>> > > > > fantastic
>>>>>>> > > > > what you've done so far. I remember someone posting "we are
>>>>>>> working on
>>>>>>> > > > > andriod
>>>>>>> > > > > in our spare time" post to spice-devel, please grep the
>>>>>>> archive.
>>>>>>> > > > >
>>>>>>> > > > > Alon
>>>>>>> > > > >
>>>>>>> > > > > > Best regards.
>>>>>>> > > > >
>>>>>>> > > > > > _______________________________________________
>>>>>>> > > > > > Spice-devel mailing list
>>>>>>> > > > > > Spice-devel at lists.freedesktop.org
>>>>>>> > > > > > http://lists.freedesktop.org/mailman/listinfo/spice-devel
>>>>>>> > > > >
>>>>>>> > > > >
>>>>>>> > >
>>>>>>> > > > _______________________________________________
>>>>>>> > > > Spice-devel mailing list
>>>>>>> > > > Spice-devel at lists.freedesktop.org
>>>>>>> > > > http://lists.freedesktop.org/mailman/listinfo/spice-devel
>>>>>>> > >
>>>>>>> > >
>>>>>>>
>>>>>>> > _______________________________________________
>>>>>>> > Spice-devel mailing list
>>>>>>> > Spice-devel at lists.freedesktop.org
>>>>>>> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Spice-devel mailing list
>>>> Spice-devel at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/spice-devel
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20110318/b96475da/attachment.htm>
More information about the Spice-devel
mailing list