Bug#678679: Spice, current status and the fueture in Debian
On Wed, Jun 27, 2012 at 04:46:41PM +0930, Ron wrote: So far as I can see, you Michael and I all agree that the experimental package is the only viable candidate for Wheezy. But you will lose that option if you do not upload it very, very soon. The freeze happens in the next few days. Michael, do you agree to upload spice 0.10.1-3~nocelt in experimental to unstable ? If you don't have time, I can upload. Thanks and Regards, -- Liang Guo http://bluestone.cublog.cn signature.asc Description: Digital signature
Bug#678679: Spice, current status and the fueture in Debian
28.06.2012 16:43, Liang Guo wrote: On Wed, Jun 27, 2012 at 04:46:41PM +0930, Ron wrote: So far as I can see, you Michael and I all agree that the experimental package is the only viable candidate for Wheezy. But you will lose that option if you do not upload it very, very soon. The freeze happens in the next few days. Michael, do you agree to upload spice 0.10.1-3~nocelt in experimental to unstable ? If you don't have time, I can upload. Yes, this should be a good candidate for the upload. The problem I have is not a time, but lack of any real internet access (I'm in a hotel till Jun-30). So if you can do the upload, please do it, maybe adding whatever other changes you think are missing still. I was hoped to have a more recent version of spice in wheezy, so maybe even the 0.11 version is better, but it is up to you (the nocelt patch should apply cleanly to 0.11 too). Thank you very much! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678679: Spice, current status and the fueture in Debian
On Wed, Jun 27, 2012 at 12:34:36PM +0800, Liang Guo wrote:
On Mon, Jun 25, 2012 at 05:29:09PM +0300, Michael Tokarev wrote:
Why do you say the package is in bad shape ? Please explain.
Current version in experimental, if not counting the removal of
celt, should be quite good, no?
IMO, spice 0.10.1-3~nocelt in experimental is in good shape, spice
0.10.1-2 with celt embedded in sid is not.
Then you have nothing to lose by pushing the experimental version to
unstable as soon as possible - but this must be done today or tomorrow
or you will miss the freeze window and your options will be very much
reduced.
Now, I think the best course to take is:
1) push current experimental, celt-less version to unstable,
after some basic verifications of audio.
2) maybe update to 0.11, to at least fix known bugs.
It is unclear whenever upstream will support 0.10 stable version, but
it is more
no than yes, or else the 32bit bug should have been fixed long ago.
3) depending on the result (if it works at all or not ;), either keep it
this way or drop it from wheezy entirely.
How can we test spice with celt removed to make sure it works fine? if we
can and we do the test. I think it's OK to ship spice without celt to wheezy,
and no technical committee decision is needed.
Consider another situation, we can do some simple test aganst spice with
our patch that removes celt support, spice client {with, without} celt can
connect to spice server {with, without} celt, and audio works, but we cannot
test spice without celt with older spice used by other platform, should
we include our spice without celt to wheezy or remove it? This is what
I want technical committee to help us to decide.
It will take the tech-ctte a considerable amount of time and work to be in
a position to judge this better than you and Michael can. This is a job for
the normal package maintainers to do.
If you say the current package in unstable is in 'bad shape', then if you
miss the freeze for uploading the experimental one, your only option will
be to remove it. If you put the version in experimental into unstable,
then you still have the option to remove it later if problems are reported
that become showstoppers. (since they would become release critical bugs
that 'automatically' get it removed if they can't be reasonably fixed)
Sure thing the best will be to have opus support in spice in wheezy. And
this is the most close variant I can think of.
I think opus should be added upstream first, then backported to debian or wait
upstream release a version with opus support. If we add opus support ourself,
upstream may add opus support with a way that may not compatible with us, then
we will be in a passive position.
Nobody is proposing that *we* do this. It has been discussed with upstream
and they are working on it. When they have something to test, then you can
begin testing it.
So far as I can see, you Michael and I all agree that the experimental
package is the only viable candidate for Wheezy. But you will lose that
option if you do not upload it very, very soon. The freeze happens in
the next few days.
Ron
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678679: Spice, current status and the fueture in Debian
On Mon, Jun 25, 2012 at 05:29:09PM +0300, Michael Tokarev wrote:
23.06.2012 20:26, Liang Guo wrote:
Alon Levy is working on adding opus codec support to spice, but it is
not merged into upstream git yet. Even opus codec support is added by
upstream, in order to compatible with the previous version, they may
not remove celt051 codec soon.
3) Current status of spice in Debian
At the end of the discussion in bug 603699, I decide to package spice
with a embeded celt051, and celt051 runtime library is in package
libspice-server1[6] now. Spice package is in a bad shape, but it
provide the same function as the upstream.
Why do you say the package is in bad shape ? Please explain.
Current version in experimental, if not counting the removal of
celt, should be quite good, no?
IMO, spice 0.10.1-3~nocelt in experimental is in good shape, spice
0.10.1-2 with celt embedded in sid is not.
Embedding celt in spice cause celt not available in other
archetecture, if other package ,spice-gtk for example, need
celt, it wll be limited to spice supported archetecture.
4) The fueture
4.1 Remove spice celt051 support in Debian
Actually spice support another codec: RAW, when using raw codec, audio
streams is not compressed, so more bandwidth is consumed, When using
spice in Internet, the latency will become large and introduce bad
user experience.
This is what some upstream developers are saying: don't remove/disable
celt051 due to some bad user expirence this causes. Without audio
compression, spice will be less useful on slow links since audio will
work worse (require more bandwidth, will be jumpy or not work at all).
Note there's no bandwidth requirements on spice site at all, be it
with celt or without.
Michael have tested the compatibility for spice server with and
without celt051 and spice client with and without celt051, and send
the patch[8] to the upstream, but the upstream refused to apply this
patch, they insist spice should come with celt051 support now.
I have run some tests, yes, but I'm really not sure I did it right,
since I don't really know how to ensure the audio is transferred
using spice and not by using some other mean.
We can apply this patch and ship spice without celt in Debian, but for
we are not expert on spice and celt, and lack necessary device to test
the compatibility with the upstream release, we may in the risk of
shipping spice that not compatible with spice in other distribution.
And there's one more issue here. Reportedly (according to upstream
spice developers), a) some older versions of spice didn't support
RAW audio stream properly (were buggy), so these wont work with
celt-crippled version of spice, but I for one didn't find definitive
answers about which versions were buggy and how and where these were
shipped with. And b) even the current version of spice hasn't really
been tested much in RAW audio stream mode. I'd not be surprized if
the only tests of this mode ever made were mine, but I'm not even sure
I actually ran spice-transferred audio or not. So there's alot of
uncertainity in there.
4.2 Completely remove spice
If spice is removed from Debian, We will not able to use debian as a
spice server or spice client.
This is a bad move, since spice is very frequently used feature with
qemu/kvm, and we'll have to deal with possible incompatibles within
libvirt too, who may expect to use spice-enabled qemu/kvm. But it
is definitely one of possible solutions.
We can still run Debian in RHEV or other spice compatible qemu/kvm
hypervisor, xserver-xorg-video-qxl and spice-vdagent don't use celt.
Thank you for your kindly help.
Now, I think the best course to take is:
1) push current experimental, celt-less version to unstable,
after some basic verifications of audio.
2) maybe update to 0.11, to at least fix known bugs.
It is unclear whenever upstream will support 0.10 stable version, but it
is more
no than yes, or else the 32bit bug should have been fixed long ago.
3) depending on the result (if it works at all or not ;), either keep it
this way or drop it from wheezy entirely.
How can we test spice with celt removed to make sure it works fine? if we
can and we do the test. I think it's OK to ship spice without celt to wheezy,
and no technical committee decision is needed.
Consider another situation, we can do some simple test aganst spice with
our patch that removes celt support, spice client {with, without} celt can
connect to spice server {with, without} celt, and audio works, but we cannot
test spice without celt with older spice used by other platform, should
we include our spice without celt to wheezy or remove it? This is what
I want technical committee to help us to decide.
(I assume upstream will test celt with older release, but I know nothing
about upstream work flow).
4) if it will work okay, maybe we'll have a chance before wheezy release to
have a
Bug#678679: Spice, current status and the fueture in Debian
Hi, Most of this is Michael's reply, cc'd verbatim to the bug now instead of to submit@ :) I have just a couple of small clarifications to add, but agree with Michael that this doesn't really seem like a question for -ctte, he and I have both been talking to upstream with mostly productive results, and I have no reason to doubt at this stage that the people involved won't sort out the best thing to do amongst themselves - even if that will take a little time to complete and converge. On Mon, Jun 25, 2012 at 05:29:09PM +0300, Michael Tokarev wrote: 23.06.2012 20:26, Liang Guo wrote: Package: tech-ctte Severity: normal Hi, Technical Committee, We'd like to decide how the spice[1] should be maintained in Debian. 1) Background The Simple Protocol for Independent Computing Environments (SPICE) is a remote display system built for virtual environments, just like vnc or remote desktop, but provide more rich feature and better performance. SPICE was developed by Qumranet[2], which was acquared by RedHat, RedHat is the primary sponsor of SPICE and includes it in RHEL (since 5.4) and RHEV platform. Spice has 2 different part, server part and client part, server part is intergrated to qemu, client part can be a standalone program, such as spice-gtk and virt-viewer, or run as a browser plugin. Spice client and spice server communicate with tcp socket. Spice can only works on x86 and i386 platform now. Spice project provide xserver-xorg-video-qxl and spice-vdagent as the guest xserver driver and the guest helper program to provide copy/pause support in qemu/kvm guest OS. 2) Celt, the root of our problem Spice uses celt[3] for audio codec. Different celt version may use different bitstream, it means that if Spice client want to correctly decode audio codec from spice server, it should use the same celt version as the spice server. For compatibility or other reason, the upstream decide to pin to celt 0.5.1. Celt is already in Debian[4], and is maintained by Ron Lee. For celt 0.5.1 is not maintained by upstream any more, including it in Debian may introduce potential security problem, so we decide to not include it in Debian. this problem has been discussed at bug 603699[5]. According messages from Ron, celt is offically dead, the upstream will not maintain it any more. A new codec, opus, is published as RFC by the IETF CODEC working group, and is encouraged to replace celt. Yes, this is basically the story behind spice and celt. Alon Levy is working on adding opus codec support to spice, but it is not merged into upstream git yet. Even opus codec support is added by upstream, in order to compatible with the previous version, they may not remove celt051 codec soon. 3) Current status of spice in Debian At the end of the discussion in bug 603699, I decide to package spice with a embeded celt051, and celt051 runtime library is in package libspice-server1[6] now. Spice package is in a bad shape, but it provide the same function as the upstream. Why do you say the package is in bad shape ? Please explain. Current version in experimental, if not counting the removal of celt, should be quite good, no? I know the library has known bugs (for one, it does not work with 32bit userspace at all), but it is upstream bug, and the fix isn't easily backportable to current stable version (0.10) -- I tried. If this is the only issue, we don't have much alternatives here (celt issues aside) but to either keep 0.10 (stable with known bugs), or to update to 0.11 which is a development version. And this is a good question to ask/answer. However, I don't think ctte is the right contact for this... ;) Spice client program, spice-client and spice-gtk depends on libspice-server1, for they uses celt runtime library. xserver-xorg-video-qxl and spice-vdagent are in Debian and in a good shape. According the Popcon statistics[7], 0.13% Debian users uses spice-client, 3.21% Debian uses uses libspice-server1(for qemu/kvm depends on libspice-server1, this can be traded as qemu users), so 4% qemu/kvm user uses spice-client. 4) The fueture 4.1 Remove spice celt051 support in Debian Actually spice support another codec: RAW, when using raw codec, audio streams is not compressed, so more bandwidth is consumed, When using spice in Internet, the latency will become large and introduce bad user experience. This is not correct. For raw PCM audio, the latency, if anything, will become *smaller* - potentially many orders of magnitude smaller. But my guess is that it will probably be identical, with their protocol using the same packet size for both. The minimum packet size (and hence latency) is much, much, smaller for raw PCM than it is for a frequency- domain codec like celt. As a general rule for audio coding, improvements in latency *always* come at the cost of additional bandwidth requirements, and that's true for the lowest latency modes of
Bug#678679: Spice, current status and the fueture in Debian
On Sun, Jun 24, 2012 at 4:47 AM, Kurt Roeckx k...@roeckx.be wrote: On Sun, Jun 24, 2012 at 01:26:47AM +0800, Liang Guo wrote: Package: tech-ctte Severity: normal Hi, Technical Committee, We'd like to decide how the spice[1] should be maintained in Debian. [ ... background ... ] This contains a lot of information about what the state of the package is, and what problems you're facing. But I didn't see you ask a question. Do you just seek advice on what you should do? Do you want to have more options? Do you want to override the decision of some maintainer? Do you want to delegate a decision to the ctte? I hope ctte can help to decide should we remove spice from Debian, or keep spice without celt051 support in Debian. If technical committee can give us any sugestion to improve spice in Debian, we will be very glade. Thanks, -- Liang Guo http://bluestone.cublog.cn -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678679: Spice, current status and the fueture in Debian
Package: tech-ctte Severity: normal Hi, Technical Committee, We'd like to decide how the spice[1] should be maintained in Debian. 1) Background The Simple Protocol for Independent Computing Environments (SPICE) is a remote display system built for virtual environments, just like vnc or remote desktop, but provide more rich feature and better performance. SPICE was developed by Qumranet[2], which was acquared by RedHat, RedHat is the primary sponsor of SPICE and includes it in RHEL (since 5.4) and RHEV platform. Spice has 2 different part, server part and client part, server part is intergrated to qemu, client part can be a standalone program, such as spice-gtk and virt-viewer, or run as a browser plugin. Spice client and spice server communicate with tcp socket. Spice can only works on x86 and i386 platform now. Spice project provide xserver-xorg-video-qxl and spice-vdagent as the guest xserver driver and the guest helper program to provide copy/pause support in qemu/kvm guest OS. 2) Celt, the root of our problem Spice uses celt[3] for audio codec. Different celt version may use different bitstream, it means that if Spice client want to correctly decode audio codec from spice server, it should use the same celt version as the spice server. For compatibility or other reason, the upstream decide to pin to celt 0.5.1. Celt is already in Debian[4], and is maintained by Ron Lee. For celt 0.5.1 is not maintained by upstream any more, including it in Debian may introduce potential security problem, so we decide to not include it in Debian. this problem has been discussed at bug 603699[5]. According messages from Ron, celt is offically dead, the upstream will not maintain it any more. A new codec, opus, is published as RFC by the IETF CODEC working group, and is encouraged to replace celt. Alon Levy is working on adding opus codec support to spice, but it is not merged into upstream git yet. Even opus codec support is added by upstream, in order to compatible with the previous version, they may not remove celt051 codec soon. 3) Current status of spice in Debian At the end of the discussion in bug 603699, I decide to package spice with a embeded celt051, and celt051 runtime library is in package libspice-server1[6] now. Spice package is in a bad shape, but it provide the same function as the upstream. Spice client program, spice-client and spice-gtk depends on libspice-server1, for they uses celt runtime library. xserver-xorg-video-qxl and spice-vdagent are in Debian and in a good shape. According the Popcon statistics[7], 0.13% Debian users uses spice-client, 3.21% Debian uses uses libspice-server1(for qemu/kvm depends on libspice-server1, this can be traded as qemu users), so 4% qemu/kvm user uses spice-client. 4) The fueture 4.1 Remove spice celt051 support in Debian Actually spice support another codec: RAW, when using raw codec, audio streams is not compressed, so more bandwidth is consumed, When using spice in Internet, the latency will become large and introduce bad user experience. Michael have tested the compatibility for spice server with and without celt051 and spice client with and without celt051, and send the patch[8] to the upstream, but the upstream refused to apply this patch, they insist spice should come with celt051 support now. We can apply this patch and ship spice without celt in Debian, but for we are not expert on spice and celt, and lack necessary device to test the compatibility with the upstream release, we may in the risk of shipping spice that not compatible with spice in other distribution. 4.2 Completely remove spice If spice is removed from Debian, We will not able to use debian as a spice server or spice client. We can still run Debian in RHEV or other spice compatible qemu/kvm hypervisor, xserver-xorg-video-qxl and spice-vdagent don't use celt. Thank you for your kindly help. [1] http://www.spice-space.org/ [2] http://en.wikipedia.org/wiki/Qumranet [3] http://celt-codec.org/ [4] http://packages.debian.org/search?keywords=celtsearchon=namessuite=allsection=all [5] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603699 [6] http://packages.debian.org/sid/amd64/libspice-server1/filelist [7] http://qa.debian.org/popcon.php?package=spice [8] http://lists.freedesktop.org/archives/spice-devel/2012-June/009410.html Thanks and Regards, -- Liang Guo http://bluestone.cublog.cn signature.asc Description: Digital signature
Bug#678679: Spice, current status and the fueture in Debian
On Sun, Jun 24, 2012 at 01:26:47AM +0800, Liang Guo wrote: Package: tech-ctte Severity: normal Hi, Technical Committee, We'd like to decide how the spice[1] should be maintained in Debian. [ ... background ... ] This contains a lot of information about what the state of the package is, and what problems you're facing. But I didn't see you ask a question. Do you just seek advice on what you should do? Do you want to have more options? Do you want to override the decision of some maintainer? Do you want to delegate a decision to the ctte? Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
