Debian Bug report logs - #813658
Please enable virgl support

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Martin Michlmayr <tbm@cyrius.com>

To: submit@bugs.debian.org

Subject: Please enable virgl support

Date: Wed, 3 Feb 2016 20:41:37 -0800

Package: qemu
Version: 1:2.5+dfsg-5
Severity: wishlist

It would be nice to have Virgil 3d support in QEMU
(--enable-virglrenderer).

Note that this requires virglrenderer to be packages in Debian.
I submitted an RFP (#813657).

-- 
Martin Michlmayr
http://www.cyrius.com/

Message #10 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Martin Michlmayr <tbm@cyrius.com>, 813658@bugs.debian.org

Subject: Re: Bug#813658: Please enable virgl support

Date: Thu, 4 Feb 2016 11:23:06 +0300

Control: block -1 813657
Control: tag -1 + confirmed

04.02.2016 07:41, Martin Michlmayr wrote:
> Package: qemu
> Version: 1:2.5+dfsg-5
> Severity: wishlist
> 
> It would be nice to have Virgil 3d support in QEMU
> (--enable-virglrenderer).

Yes, I've seen this feature, considered enabling it,
found out that virglrenderer isn't available and
decided to take a look later.

> Note that this requires virglrenderer to be packages in Debian.
> I submitted an RFP (#813657).

Hence adding block :)  Maybe some day we'll package it
too, if someone else wont do it before.

/mjt

Message #19 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Martin Michlmayr <tbm@cyrius.com>, 813658@bugs.debian.org

Subject: Re: Bug#813658: Please enable virgl support

Date: Tue, 9 Feb 2016 18:40:02 +0300

04.02.2016 11:23, Michael Tokarev wrote:
> 04.02.2016 07:41, Martin Michlmayr wrote:
>>
>> It would be nice to have Virgil 3d support in QEMU
>> (--enable-virglrenderer).
> 
> Yes, I've seen this feature, considered enabling it,
> found out that virglrenderer isn't available and
> decided to take a look later.
> 
>> Note that this requires virglrenderer to be packages in Debian.
>> I submitted an RFP (#813657).
> 
> Hence adding block :)  Maybe some day we'll package it
> too, if someone else wont do it before.

Note also that virgl support needs qemu to be built with SDL2,
not SDL1 which is currently used.  But SDL2 support in qemu lacks
a few other features which are available in SDL1.  We once tried
to switch to SDL2 but people complained, so we switched back.

Maybe these days things has been improved.

/mjt

Message #24 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Fabio Fantoni <fabio.fantoni@m2r.biz>

To: 813658@bugs.debian.org

Subject: Re: Bug#813658: Please enable virgl support

Date: Fri, 26 Feb 2016 10:47:28 +0100

Next qemu version added also spice support for virgl:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=474114b7305cc1be7c2ee8ba5267be159a9d56e3

I think is good start atleast virglrender package now and if will not be 
possible add it to qemu now will be done for next version using it with 
spice.

Thanks and sorry for my bad english.

Message #29 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Daniel Pocock <daniel@pocock.pro>

To: 813658@bugs.debian.org, 813658-submitter@bugs.debian.org

Subject: Re: Bug#813658: Please enable virgl support

Date: Fri, 4 Mar 2016 07:45:36 +0100

As mentioned in #813657, the virglrenderer library package is now in NEW

I asked some questions about project status, architecture and other
dependency versions on the upstream mailing list:

https://lists.freedesktop.org/archives/virglrenderer-devel/2016-March/000051.html

The main thing to note there is that they only support GNU/Linux guests
for now and the guest needs a 4.4 kernel.

Regards,

Daniel

Message #35 received at 813658-submitter@bugs.debian.org (full text, mbox, reply):

From: Daniel Pocock <daniel@pocock.pro>

To: 813658-submitter@bugs.debian.org

Subject: virglrenderer accepted in sid

Date: Mon, 14 Mar 2016 12:32:30 +0100

It has been accepted in sid, there was a bug which I fixed with another
upload yesterday, it could now be used to resolve #813658

https://packages.qa.debian.org/v/virglrenderer.html

Can somebody please approve my request to join pkg-qemu so I can push
the Git repository for this package into the group's directory on alioth?

Would somebody volunteer to upload it to jessie-backports too, so that
backported qemu packages can use it?

Message #42 received at 813658@bugs.debian.org (full text, mbox, reply):

From: intrigeri <intrigeri@debian.org>

To: 813658@bugs.debian.org

Subject: Re: Bug#813658: Please enable virgl support

Date: Mon, 04 Apr 2016 18:51:36 +0200

[Message part 1 (text/plain, inline)]

Hi,

FWIW, with the attached (git format-)patch series applied on top of
the debian/qemu_2.5+dfsg-5 tag in Vcs-Git, the output of ./configure,
while building the package in a chroot that has a locally-patched
libvirglrenderer-dev that fixes #818665, contains:

  GTK GL support    yes
  [...]
  virgl support     yes
  OpenGL support    yes

Using that QEMU, I've successfully booted a Jessie guest that has
Linux 4.4 from sid, and libdrm + Mesa from jessie-backports:

  qemu-system-x86_64 \
    -machine accel=kvm -m 2048 -cdrom whatever.iso \
    -display gtk -vga virtio

GNOME Shell works fine in the guest, X.Org uses the modesetting driver
as expected, but it seems that for some reason, virgl 3d acceleration
is not available. Next step is probably to test with a more current
(sid or Fedora rawhide) guest.

I didn't investigate any further yet, but I figured I would shared
this work in the hope it would save the maintainers some time some
day :)

Cheers,
--
intrigeri

[0001-Enable-GTK-3.0-support.patch (text/x-diff, attachment)]

[0002-Enable-virgl-and-GTK-OpenGL-support.patch (text/x-diff, attachment)]

Message #47 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Daniel Pocock <daniel@pocock.pro>

To: 813658@bugs.debian.org

Subject: Fwd: virglrenderer_0.4.0-6~bpo8+1_amd64.changes ACCEPTED into jessie-backports, jessie-backports

Date: Tue, 12 Apr 2016 15:59:25 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256




I uploaded virglrenderer to backports as well so it can be enabled in
the backports builds of qemu


- -------- Forwarded Message --------
Subject: virglrenderer_0.4.0-6~bpo8+1_amd64.changes ACCEPTED into
jessie-backports, jessie-backports
Date: Tue, 12 Apr 2016 13:01:54 +0000
From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>
To: Debian QEMU Team <pkg-qemu-devel@lists.alioth.debian.org>, Daniel
Pocock <daniel@pocock.pro>



Accepted:

Format: 1.8
Date: Fri, 08 Apr 2016 08:10:42 +0200
Source: virglrenderer
Binary: libvirglrenderer0 libvirglrenderer-dev
Architecture: source amd64
Version: 0.4.0-6~bpo8+1
Distribution: jessie-backports
Urgency: high
Maintainer: Debian QEMU Team <pkg-qemu-devel@lists.alioth.debian.org>
Changed-By: Daniel Pocock <daniel@pocock.pro>
Description:
 libvirglrenderer-dev - virtual GPU for KVM virtualization - headers
 libvirglrenderer0 - virtual GPU for KVM virtualization
Changes:
 virglrenderer (0.4.0-6~bpo8+1) jessie-backports; urgency=high
 .
   * Build for jessie-backports.
Checksums-Sha1:
 beb204768dbc4f39e622ed50355143ebe8e40be2 2214
virglrenderer_0.4.0-6~bpo8+1.dsc
 c0cce0c4aec6327b4868097d682a147374992e5c 3368
virglrenderer_0.4.0-6~bpo8+1.debian.tar.xz
 5079c3e628bf74ce5f0535bcd59490fad4f14e28 120716
libvirglrenderer0_0.4.0-6~bpo8+1_amd64.deb
 083584d10d24456b0a40ed416451d72408703ed9 5258
libvirglrenderer-dev_0.4.0-6~bpo8+1_amd64.deb
Checksums-Sha256:
 e927994233e145c6cb83ac51c315bf7d393b995afb1940e2fd41712a25288bd7 2214
virglrenderer_0.4.0-6~bpo8+1.dsc
 e7407926b05e33ee22ea4e7602ab87d5d26863a3cbf0cec6946ee3785edf1b81 3368
virglrenderer_0.4.0-6~bpo8+1.debian.tar.xz
 54e4937dca192bc71c8cc5558dfe7216d62f36db7c9f00e2b447600cc2892c3b 120716
libvirglrenderer0_0.4.0-6~bpo8+1_amd64.deb
 8eaba65e1f19ae8e116983c696a7af0344418690d496260be83719d29c57816a 5258
libvirglrenderer-dev_0.4.0-6~bpo8+1_amd64.deb
Files:
 7fb36d1b59650e70f42274b9fb4bdf3c 2214 libs extra
virglrenderer_0.4.0-6~bpo8+1.dsc
 81b36e2b33ba0c51564502c6e71eb052 3368 libs extra
virglrenderer_0.4.0-6~bpo8+1.debian.tar.xz
 a2c53629c0c0592877a2a0ce3c54fffb 120716 libs extra
libvirglrenderer0_0.4.0-6~bpo8+1_amd64.deb
 4bd162ee3b223afe362c5f881642ec88 5258 libdevel extra
libvirglrenderer-dev_0.4.0-6~bpo8+1_amd64.deb



Thank you for your contribution to Debian.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXDP89AAoJEGxlgOd711bErn8QAJ+GwmZK3jwUA6OKQrBksall
VdqaKFFo3yeSiUsyRsGPywWMIAveydAlQtC1skJQ6iu9NTQCQxLKb8KTonSUXKz2
V82vFCps4U0ZBkPDYhJ2eQvadTmQsJQK3IYE+vVFHIrIBO+008NUIrjz9lb4jGkH
I8TQZfUXFMkIBfP5GnFF4vITYA+NDvmytYoiAC19yzfDFrEQon1uMctnZfrXgbC2
VhIJJjjgbY3ioG7u7Ee9gmexFNCyExNLcsuBOykWN28FQWoOu3lgtuUp4oP2y+Ai
xFTRH3AT6CX7tI8qT4niYmV0ubqVT/EEF2NxA1gEGryWS7KzD4yATrebh4yNsFzn
Wf3kGLYdbiJSiC3ZsZnvn2ez9qoJgHkadV83925Y9bE5limhfTVsKGgI0KYszlV8
c7fJTVQJYx+C0Y441TtptRO9z2CAg0CEi5JsetWEL4RKnGDr31x7I2N30nQ86hZd
+YViU3pqWp28FqNO+mTT4RSom3/ILkw6iBC/5jsafIlApqVq6N8TLJ/B2Uo860kv
jlgP2iYddNM5Vh5pPqHEDFuglM5VRWqnFgRSpfLw4trdxf7ACDH47kA2upjdEA2I
0o9V7+LoIKNOPLNl3aulpI1dSdzcgsmKOD8hgXNM5NnLih9gBedcvCoXkAB2LiuG
EnWOiFD/H04r1aYu7sjf
=RuOe
-----END PGP SIGNATURE-----

Message #52 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Laurent Bigonville <bigon@debian.org>

To: 813658@bugs.debian.org

Subject: Re: Please enable virgl support

Date: Tue, 23 Aug 2016 18:16:59 +0200

Hello,

Any progress on this side?

The freeze is coming closer and if we want this for stretch I guess it 
should be enabled (at least in an upload to experimental to be able to test)

Cheers,

Laurent Bigonville

Message #57 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Daniel Pocock <daniel@pocock.pro>

To: 813658@bugs.debian.org

Subject: virgl status update?

Date: Fri, 7 Oct 2016 11:54:47 +0200

Has anybody considered building with --enable-virglrenderer now that the
dependency is available in sid, stretch and jessie-backports?

It may be possible to finally close this bug and it would be good to
have it working in stretch.

Please tell me if an update of the virglrenderer package is needed or
feel free to NMU / add yourself to uploaders

Message #62 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Hillel Lubman <shmerl@mykolab.com>

To: 813658@bugs.debian.org

Subject: virglrenderer support before the freeze?

Date: Wed, 02 Nov 2016 18:24:14 -0400

[Message part 1 (text/plain, inline)]

Hi. 

Do you plan to add --enable-virglrenderer to the qemu build? Freeze is
very close, and it would be good to have this feature in before it. 

Thanks, 

Hillel Lubman.

  

[Message part 2 (text/html, inline)]

Message #67 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Hillel Lubman <shmerl@mykolab.com>, 813658@bugs.debian.org

Subject: Re: Bug#813658: virglrenderer support before the freeze?

Date: Thu, 3 Nov 2016 08:14:18 +0300

03.11.2016 01:24, Hillel Lubman wrote:
> Hi.
> 
> Do you plan to add --enable-virglrenderer to the qemu build? Freeze is
> very close, and it would be good to have this feature in before it.

The prob is that currently, with sdl1, virglrenderer doesn't quite
work. It works with sdl2 or gtk frontends, sdl1 support is very
limited.

So in order for virglrenderer to be useful, other changes are needed.
Which I'm currently evaluating.  The prob is that I tried to switch
to sdl2 before already, users complained about missing features which
were found in sdl1 support. Now it's probably best to switch to gtk
as it is the default since upstream 2.7 version (or 2.7+, I'm not sure).
Which brings up other libraries, and users already complained about
too much graphics dependencies in qemu.

The best would be to enable modular display support, the same way as
we did for block devices.  But unfortunately this fails now for sdl1,
which tends to replace main() function.  I tried to implement it, and
it almost works, except of the sdl1 issue.

Thanks,

/mjt

Message #72 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Hillel Lubman <shmerl@mykolab.com>

To: 813658@bugs.debian.org

Subject: Re: Bug#813658: virglrenderer support before the freeze?

Date: Sun, 06 Nov 2016 18:24:17 -0500

On Thu, 3 Nov 2016 08:14:18 +0300 Michael Tokarev  wrote:

> The prob is that currently, with sdl1, virglrenderer doesn't quite
> work. It works with sdl2 or gtk frontends, sdl1 support is very
> limited.
>
> So in order for virglrenderer to be useful, other changes are needed.
> Which I'm currently evaluating.  The prob is that I tried to switch
> to sdl2 before already, users complained about missing features which
> were found in sdl1 support.

What features did users complain about? May be today it's not relevant anymore. And SDL1 eventually should get deprecated
(especially since it won't work with Wayland), so users should eventually stop relying on it. I'm not sure it's even supported upstream
today. I'd say now more and more would complain that virgl isn't supported because of sticking to SDL1, so you'd need to consider
what's more important.

But if you can figure support for both SDL1 and SDL2 at the same time as a runtime choice, that would be of course ideal including legacy  cases.

Best regards,
Hillel Lubman.

Message #77 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: 813658@bugs.debian.org

Subject: Re: Bug#813658: virglrenderer support before the freeze?

Date: Wed, 9 Nov 2016 18:34:45 +0300

I looked at this matter a bit more.  I switched from sdl1 to gtk3
and enabled gl and virglrenderer.  It works.

But now, we're facing quite an.. interesting issue.

On all my servers where qemu is used, upgrading to this new
version pulls in a TON of new dependencies, including wayland
(libwayland-SERVER too), dconf-service, gnome icon themes,
all mesa and drm libs and other things.

Very similar thing happens when I just switch sdl1 to sdl2,
but in this case it does not pull that many gnome things,
still depending on all drm and wayland libs.

Once we enable that, all server people will start screaming
out very very loud.

We need to either make display modular (that'd be the best),
with modules like qemu-system-display-gtk etc, or we need to
create a headless package as a temporary measure.

Now, we have various qemu-system-$ARCH packages, making a
headless variant for all of them is just insane.  Maybe
single qemu-system-native-headless will do the trick, for
most cases anyway (only on a few arches where this makes
sense), I'm not sure.

I can enable virglrenderer, but without sdl2 or gtk3 together
with mesa it wont'd do any thing.

Suggestions? :)

Thanks,

/mjt

Message #82 received at 813658@bugs.debian.org (full text, mbox, reply):

From: intrigeri <intrigeri@debian.org>

To: 813658@bugs.debian.org

Subject: Re: Bug#813658: virglrenderer support before the freeze?

Date: Wed, 09 Nov 2016 17:43:27 +0100

Hi,

Michael Tokarev:
> I looked at this matter a bit more.  I switched from sdl1 to gtk3
> and enabled gl and virglrenderer.  It works.

Thanks a lot for looking into it! I'm interested in this because
a number of people run Tails in virtual machines, and virt-manager +
QEMU is our best supported platform so far.

> On all my servers where qemu is used, upgrading to this new
> version pulls in a TON of new dependencies,
> […]
> Once we enable that, all server people will start screaming
> out very very loud.

Thanks for these details! Now, I'd like to understand better why
exactly this is a problem serious enough that 1. it will make people
scream very very loud; 2. it needs to be solved by other people than
those who care that much about the list of packages installed on their
virtualization hosts.

The dependencies you list are mostly libraries, that are harmless even
in a server context, so I assume that the biggest problem is disk
space, right?

If I'm guessing correctly: can you quantify how much additional disk
space these dependencies requires?

Obviously I can't speak for most QEMU administrators, but at least in
the context I'm familiar with (libvirt host with a few dozens VMs), my
virtualization hosts are beefy and stuffed with storage well enough to
cope with a few additional hundreds of MiB needed by additional
dependencies, without any problem… and if my initial partitioning did
not leave room for that, the kind of people who admin such systems
should have no problem with extending a LV :)

> Maybe single qemu-system-native-headless will do the trick, for most
> cases anyway (only on a few arches where this makes sense), I'm
> not sure.

This sounds good enough a solution for Stretch (if there's really
a problem to solve :)

Cheers,
-- 
intrigeri

Message #87 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

To: intrigeri <intrigeri@debian.org>, 813658@bugs.debian.org

Subject: Re: Bug#813658: virglrenderer support before the freeze?

Date: Wed, 9 Nov 2016 22:00:22 +0100

Hi intrigeri,

On 09.11.2016 17:43, intrigeri wrote:
> Michael Tokarev:
>> I looked at this matter a bit more.  I switched from sdl1 to gtk3
>> and enabled gl and virglrenderer.  It works.
> 
> Thanks a lot for looking into it! I'm interested in this because
> a number of people run Tails in virtual machines, and virt-manager +
> QEMU is our best supported platform so far.

If you want to use virgl with virt-manager you don't need to enable
gtk3 or sdl2, only virglrenderer and opengl.
However, you also need a newer libspice-server-dev (0.13.2).
With qemu built that way virgl works fine for virt-manager and
even gnome-boxes.

Best regards,
Andreas

Message #92 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>, 813658@bugs.debian.org, intrigeri <intrigeri@debian.org>

Subject: Re: Bug#813658: virglrenderer support before the freeze?

Date: Mon, 14 Nov 2016 13:02:36 +0300

10.11.2016 00:00, Andreas Cadhalpun wrote	:
> Hi intrigeri,
> 
> On 09.11.2016 17:43, intrigeri wrote:
>> Michael Tokarev:
>>> I looked at this matter a bit more.  I switched from sdl1 to gtk3
>>> and enabled gl and virglrenderer.  It works.
>>
>> Thanks a lot for looking into it! I'm interested in this because
>> a number of people run Tails in virtual machines, and virt-manager +
>> QEMU is our best supported platform so far.
> 
> If you want to use virgl with virt-manager you don't need to enable
> gtk3 or sdl2, only virglrenderer and opengl.

This does not help, unfortunately. Yesterday I wrote a quick hack
to made gtk3 display modular, this works fine.  However, linking
with virglrenderer brings half of the X/drm stack back again.
I've no idea how virglrenderer works and why it needs CLIENT
libs on a display-less program... :(

Anyone know how this is supposed to work or to be used?
As far as I can see, virglrenderer usage in qemu is "headless",
as in, it doesn't do actual displaying (when omitting gtk/sdl
display). Why it needs libwayland, libdrm and various drm-radeon
and similar? Maybe virglrenderer should be split up into two
parts, say, headless and headful? :)

> However, you also need a newer libspice-server-dev (0.13.2).
> With qemu built that way virgl works fine for virt-manager and
> even gnome-boxes.

0.13 is a beta release, should it be pushed to Debian at this
time?

Thanks,

/mjt

Message #97 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: intrigeri <intrigeri@debian.org>, 813658@bugs.debian.org

Subject: Re: Bug#813658: virglrenderer support

Date: Mon, 14 Nov 2016 13:12:26 +0300

09.11.2016 19:43, intrigeri wrote:
> Michael Tokarev:
[]
>> On all my servers where qemu is used, upgrading to this new
>> version pulls in a TON of new dependencies,
>> […]
>> Once we enable that, all server people will start screaming
>> out very very loud.
> 
> Thanks for these details! Now, I'd like to understand better why
> exactly this is a problem serious enough that 1. it will make people
> scream very very loud; 2. it needs to be solved by other people than
> those who care that much about the list of packages installed on their
> virtualization hosts.
> 
> The dependencies you list are mostly libraries, that are harmless even
> in a server context, so I assume that the biggest problem is disk
> space, right?

Well. It's a lot of libs, most of them are complex, and with various
security issues.  During jessie lifetime, I've seen more security
fixes in "headful" part of packages (on my desktop system) than on
a headless server install. Pushing all these client libs to server
means many more security fixes which needs to be reviewed.  Most of
these will be just unused baggage which just needs constant attention.

The prob isn't the disk space, no, disks are cheap these days. But
the maintenance on the end-user part.

I dunno. Maybe I'm too old-fasioned, and used to nice and clean
systems.

We had numerous requests to create qemu-system-headless package(s),
and numerous complains that virtualization brings up lots of unnecessary
dependencies.  We've a bug report about this open, too. And we already
had that - when I switched to gtk2 (at the time), several people wrote
to me asking about the new baggage (in UNSTABLE!) for servers with
gtk2 (I had to revert back to sdl1 because gtk support wasn't ready,
or else I'd had to deal with that baggage requests).

I dunno.  For me myself I'd not add the extra stuff for our servers
if it's possible to avoid that. But that's just me. I understand
other people have different uses.

If it all were easily separatable, that'd be great...  I already
sort-of-modularized gtk. Now virtio-gpu needs to be modularized
too (or else virglrenderer brings most of that baggage back),
but how many packages we'll have to create? As stated in other
email, virglrendered can be used with spice too, so it can't
be part of qemu-system-display-gtk (say) package, it needs to
be in separate package which is recommended by q-s-display-gtk
and q-s-display-spice (say) packages... Oh well..

Any other thoughts? :)

Thanks,

/mjt

Message #102 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>

To: Michael Tokarev <mjt@tls.msk.ru>, 813658@bugs.debian.org, intrigeri <intrigeri@debian.org>

Subject: Re: Bug#813658: virglrenderer support before the freeze?

Date: Mon, 14 Nov 2016 19:39:22 +0100

On 14.11.2016 11:02, Michael Tokarev wrote:
> 10.11.2016 00:00, Andreas Cadhalpun wrote	:
>> If you want to use virgl with virt-manager you don't need to enable
>> gtk3 or sdl2, only virglrenderer and opengl.
> 
> This does not help, unfortunately. Yesterday I wrote a quick hack
> to made gtk3 display modular, this works fine.  However, linking
> with virglrenderer brings half of the X/drm stack back again.
> I've no idea how virglrenderer works and why it needs CLIENT
> libs on a display-less program... :(

The only additional dependencies compared to the current
qemu-system-x86 package are:
libdrm2 libepoxy0 libexpat1 libgbm1 libvirglrenderer0
libwayland-client0 libwayland-server0

That doesn't seem excessive to me.

> Anyone know how this is supposed to work or to be used?
> As far as I can see, virglrenderer usage in qemu is "headless",
> as in, it doesn't do actual displaying (when omitting gtk/sdl
> display). Why it needs libwayland, libdrm and various drm-radeon
> and similar? Maybe virglrenderer should be split up into two
> parts, say, headless and headful? :)

I've no idea how it works, but how to use it is described on
various websites, e.g. [1].

>> However, you also need a newer libspice-server-dev (0.13.2).
>> With qemu built that way virgl works fine for virt-manager and
>> even gnome-boxes.
> 
> 0.13 is a beta release, should it be pushed to Debian at this
> time?

I'm aware that it is a development release and I don't know
what that implies for ABI/API stability.
However, I'd be delighted to have qemu supporting virgl over
spice in stretch.

Best regards,
Andreas


1: https://www.kraxel.org/blog/2016/09/using-virtio-gpu-with-libvirt-and-spice/

Message #107 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Erik Adler <erik.adler@gmail.com>

To: 813658@bugs.debian.org

Subject: Re: Bug#813658: virglrenderer support before the freeze?

Date: Mon, 5 Dec 2016 22:54:23 +0100

[Message part 1 (text/plain, inline)]

>> 0.13 is a beta release, should it be pushed to Debian at this
>> time?

> I'm aware that it is a development release and I don't know
> what that implies for ABI/API stability.
> However, I'd be delighted to have qemu supporting virgl over
> spice in stretch.

Most people using a desktop environment will want to use Virt-Manager +
virgl over Spice.
As mentioned there is no need to enable gtk3 or sdl2 just virglrenderer and
opengl.
The performance gains are stunning when using virgl[1].

IMHO the above dependencies would be well worth its weight for such
benefits.

Spice-server 13.1 was released over eight months ago. I have not noticed
any "major" issues
with this branch. I too would love to see virgl in Stretch. If this is not
possible maybe
we could hope for a backport? Quite a few flavors of GNU/Linux are already
using Spice 13.x
as is though.

[1] www.youtube.com/watch?v=4nXAv3u5e3g


All the best
Erik aka Onryo

Signature:
GPG/PGP key ID: 0x2B4B58FE
gpg --keyserver pgp.mit.edu --recv-keys 0x2B4B58FE

[Message part 2 (text/html, inline)]

Message #112 received at 813658@bugs.debian.org (full text, mbox, reply):

From: john <johnw.mail@gmail.com>

To: Debian Bug Tracking System <813658@bugs.debian.org>

Subject: Re: Please enable virgl support

Date: Fri, 16 Dec 2016 09:41:47 +0800

Package: qemu-system-x86
Version: 1:2.7+dfsg-3+b1
Followup-For: Bug #813658

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

	Hi, Is it possible use virgl/opengl with debian's package?
	(No recompile or hand make binary)

	When I launch qemu-system-x86_64 -args .... -display,gl=on
	(which is "man qemu-system-x86_64" say),
	It complain "SDL1 display code has no opengl support" issus.

	Please make debian's qemu package support virgl/opengl, thanks.

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-1-grsec-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qemu-system-x86 depends on:
ii  ipxe-qemu           1.0.0+git-20161027.b991c67-1
ii  libaio1             0.3.110-3
ii  libasound2          1.1.2-1
ii  libbluetooth3       5.43-1
ii  libbrlapi0.6        5.4-3
ii  libc6               2.24-8
ii  libcacard0          1:2.5.0-2
ii  libfdt1             1.4.2-1
ii  libgcc1             1:6.2.1-6
ii  libglib2.0-0        2.50.2-2
ii  libgnutls30         3.5.7-2
ii  libjpeg62-turbo     1:1.5.1-2
ii  libncurses5         6.0+20161126-1
ii  libnettle6          3.3-1
ii  libpixman-1-0       0.34.0-1
ii  libpng16-16         1.6.26-6
ii  libpulse0           9.0-5
ii  libsasl2-2          2.1.27~101-g0780600+dfsg-1
ii  libsdl1.2debian     1.2.15+dfsg1-4
ii  libseccomp2         2.3.1-2.1
ii  libspice-server1    0.12.8-1
ii  libtinfo5           6.0+20161126-1
ii  libusb-1.0-0        2:1.0.21-1
ii  libusbredirparser1  0.7.1-1
ii  libuuid1            2.29-1
ii  libvdeplug2         2.3.2+r586-2.1
ii  libx11-6            2:1.6.4-2
ii  libxen-4.8          4.8.0~rc5-1
ii  libxenstore3.0      4.8.0~rc5-1
ii  qemu-system-common  1:2.7+dfsg-3+b1
ii  seabios             1.9.3-2
ii  zlib1g              1:1.2.8.dfsg-4

Versions of packages qemu-system-x86 recommends:
ii  qemu-utils  1:2.7+dfsg-3+b1

Versions of packages qemu-system-x86 suggests:
ii  kmod              23-1
pn  ovmf              <none>
pn  qemu-block-extra  <none>
pn  samba             <none>
pn  sgabios           <none>
pn  vde2              <none>

-- no debconf information

Message #117 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: john <johnw.mail@gmail.com>, 813658@bugs.debian.org

Subject: Re: Bug#813658: Please enable virgl support

Date: Fri, 16 Dec 2016 15:05:27 +0300

16.12.2016 04:41, john wrote:
> Package: qemu-system-x86
> Version: 1:2.7+dfsg-3+b1
> Followup-For: Bug #813658
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
> 	Hi, Is it possible use virgl/opengl with debian's package?
> 	(No recompile or hand make binary)
> 
> 	When I launch qemu-system-x86_64 -args .... -display,gl=on
> 	(which is "man qemu-system-x86_64" say),
> 	It complain "SDL1 display code has no opengl support" issus.
> 
> 	Please make debian's qemu package support virgl/opengl, thanks.
> 
> *** End of the template - remove these template lines ***

John, out of curiocity, what is the reason of this your
follow-up, why you sent it? Do you happen to know how to
deal with the concerns outlined in this bugreport already?

Thanks,

/mjt

Message #122 received at 813658@bugs.debian.org (full text, mbox, reply):

From: johnw <johnw.mail@gmail.com>

To: Michael Tokarev <mjt@tls.msk.ru>, 813658@bugs.debian.org

Subject: Re: Bug#813658: Please enable virgl support

Date: Sat, 17 Dec 2016 09:26:23 +0800

[Message part 1 (text/plain, inline)]

On 12/16/2016 08:05 PM, Michael Tokarev wrote:
> 16.12.2016 04:41, john wrote:
>> Package: qemu-system-x86
>> Version: 1:2.7+dfsg-3+b1
>> Followup-For: Bug #813658
>>
>> Dear Maintainer,
>>
>> *** Reporter, please consider answering these questions, where appropriate ***
>>
>> 	Hi, Is it possible use virgl/opengl with debian's package?
>> 	(No recompile or hand make binary)
>>
>> 	When I launch qemu-system-x86_64 -args .... -display,gl=on
>> 	(which is "man qemu-system-x86_64" say),
>> 	It complain "SDL1 display code has no opengl support" issus.
>>
>> 	Please make debian's qemu package support virgl/opengl, thanks.
>>
>> *** End of the template - remove these template lines ***
> John, out of curiocity, what is the reason of this your
> follow-up, why you sent it? Do you happen to know how to
> deal with the concerns outlined in this bugreport already?
>
> Thanks,
>
> /mjt
>
Hi Michael,

No, unfortunately I do not have any idea, how to deal with. :(

I send this mail, because I have this problem and want to know people
how to solve it,

So, I want to follow the bugreport, maybe someday developer will solve it.

Thanks.

[signature.asc (application/pgp-signature, attachment)]

Message #127 received at 813658-close@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: 813658-close@bugs.debian.org

Subject: Bug#813658: fixed in qemu 1:2.8+dfsg-1

Date: Wed, 28 Dec 2016 13:35:00 +0000

Source: qemu
Source-Version: 1:2.8+dfsg-1

We believe that the bug you reported is fixed in the latest version of
qemu, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 813658@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Tokarev <mjt@tls.msk.ru> (supplier of updated qemu package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Wed, 28 Dec 2016 15:31:37 +0300
Source: qemu
Binary: qemu qemu-system qemu-block-extra qemu-system-common qemu-system-misc qemu-system-arm qemu-system-mips qemu-system-ppc qemu-system-sparc qemu-system-x86 qemu-user qemu-user-static qemu-user-binfmt qemu-utils qemu-guest-agent qemu-kvm
Architecture: source amd64
Version: 1:2.8+dfsg-1
Distribution: unstable
Urgency: medium
Maintainer: Debian QEMU Team <pkg-qemu-devel@lists.alioth.debian.org>
Changed-By: Michael Tokarev <mjt@tls.msk.ru>
Description:
 qemu       - fast processor emulator
 qemu-block-extra - extra block backend modules for qemu-system and qemu-utils
 qemu-guest-agent - Guest-side qemu-system agent
 qemu-kvm   - QEMU Full virtualization on x86 hardware
 qemu-system - QEMU full system emulation binaries
 qemu-system-arm - QEMU full system emulation binaries (arm)
 qemu-system-common - QEMU full system emulation binaries (common files)
 qemu-system-mips - QEMU full system emulation binaries (mips)
 qemu-system-misc - QEMU full system emulation binaries (miscellaneous)
 qemu-system-ppc - QEMU full system emulation binaries (ppc)
 qemu-system-sparc - QEMU full system emulation binaries (sparc)
 qemu-system-x86 - QEMU full system emulation binaries (x86)
 qemu-user  - QEMU user mode emulation binaries
 qemu-user-binfmt - QEMU user mode binfmt registration for qemu-user
 qemu-user-static - QEMU user mode emulation binaries (static version)
 qemu-utils - QEMU utilities
Closes: 758189 775431 813658 819755 833162 833619 837191 837316 839695 839834 839835 840228 840236 840340 840341 840343 840945 840948 841950 841955 842463 844361 846797 847381 847382 847391 847400 847496 847951 847953 847957 847960
Changes:
 qemu (1:2.8+dfsg-1) unstable; urgency=medium
 .
   * new upstream release
    Closes: #837191, CVE-2016-7156
    Closes: #837316, CVE-2016-7170
    Closes: #839835, CVE-2016-7908
    Closes: #839834, CVE-2016-7909
    Closes: #840228, CVE-2016-7994
    Closes: #840236, CVE-2016-7995
    Closes: #840343, CVE-2016-8576
    Closes: #840341, CVE-2016-8577
    Closes: #840340, CVE-2016-8578
    Closes: #840948, CVE-2016-8668
    Closes: #840945, CVE-2016-8669
    Closes: #841950, CVE-2016-8909
    Closes: #841955, CVE-2016-8910
    Closes: #842463, CVE-2016-9102 CVE-2016-9103 CVE-2016-9104
                     CVE-2016-9105 CVE-2016-9106
    Closes: #846797, CVE-2016-9776
    Closes: #847381, CVE-2016-9845
    Closes: #847382, CVE-2017-9846
    Closes: #847953, CVE-2016-9907
    Closes: #847400, CVE-2016-9908
    Closes: #847951, CVE-2016-9911
    Closes: #847391, CVE-2016-9912
    Closes: #847496, CVE-2016-9913 CVE-2016-9914 CVE-2016-9915 CVE-2016-9916
    Closes: #847960, CVE-2016-9921 CVE-2016-9922
    Closes: #847957, CVE-2016-9923
    Closes: #819755, #833162
    Hopefully closes: #844361
   * remove unicore32 linux-user target, removed upstream
   * remove all patches which were applied upstream (most of them)
   * actually fix #841060
   * doc-don-t-mention-memory-it-is-m.patch, Closes: #833619
   * don't pass --enable-uuid (always enabled)
   * build-depend on libncursesw5-dev, not libncurses5-dev
   * install trace-events-all in qemu-system-common
   * do not install qemu-tech.html (not provided by upstream anymore)
   * switch from sdl1 to gtk3 (Closes: #839695)
   * enable virtio gpu (virglrenderer) and opengl support (Closes: #813658)
   * strip out -ldrm out of OPENGL_LIBS, since libdrm is actually not needed
   * enable nfs support (libnfs-dev), in qemu-block-extra
   * enable glusterfs support (glusterfs-common), in qemu-block-extra
     (Closes: #775431)
   * enable numa support (libnuma-dev) (Closes: #758189)
Checksums-Sha1:
 e099f46bc489cf76eacd8d2bcc083516fc986349 5596 qemu_2.8+dfsg-1.dsc
 fa9150a6c78c7758900878011d0ff62831695f1c 7040728 qemu_2.8+dfsg.orig.tar.xz
 27d250b522a25ce4fc5ad44498f7cd7e35085b1d 69456 qemu_2.8+dfsg-1.debian.tar.xz
 41fde80df8e594bb65b27a3c8d3ce69c89f3e1c9 275206 qemu-block-extra-dbgsym_2.8+dfsg-1_amd64.deb
 4ad1bde8302f3919d7f4426f4bdeab6e4d1c9415 101326 qemu-block-extra_2.8+dfsg-1_amd64.deb
 10068dcde8af925ba8b0cf64f6bf3af58f2114fc 769340 qemu-guest-agent-dbgsym_2.8+dfsg-1_amd64.deb
 0f19a6dc73f70d5e576eee751d5d1930832167f0 310290 qemu-guest-agent_2.8+dfsg-1_amd64.deb
 98eed5c0e1e0a01adcf9d021d13b1ba0c3bbc143 62852 qemu-kvm_2.8+dfsg-1_amd64.deb
 a46cdea797f266002f22e8f7601c94ab334c70e0 38352992 qemu-system-arm-dbgsym_2.8+dfsg-1_amd64.deb
 89e88f6b72938deb77943e3b1498ba5482a90f26 5271794 qemu-system-arm_2.8+dfsg-1_amd64.deb
 4a16186462674bb80921ed2deaf9a52132925f43 327546 qemu-system-common-dbgsym_2.8+dfsg-1_amd64.deb
 9bb08c7a475cfc924ee7fc27abe32c90b8c7e88f 499894 qemu-system-common_2.8+dfsg-1_amd64.deb
 10cbfffd99eca29161c1c741068bd01218733fdf 64245376 qemu-system-mips-dbgsym_2.8+dfsg-1_amd64.deb
 c6b2d751b31e1641e038e384db68d233f01619cf 9000906 qemu-system-mips_2.8+dfsg-1_amd64.deb
 81426838e6c7ffa65b1ca2ec175809904a050348 170188102 qemu-system-misc-dbgsym_2.8+dfsg-1_amd64.deb
 e0cd6c158e40ce86fc22ea54dce8986826557ae9 13542652 qemu-system-misc_2.8+dfsg-1_amd64.deb
 1ac25703e8cdcac08b1bf4761464e991d003df2f 49329478 qemu-system-ppc-dbgsym_2.8+dfsg-1_amd64.deb
 20e39daec31d5bb617a3d0dd143090fe47a632e3 7029742 qemu-system-ppc_2.8+dfsg-1_amd64.deb
 4055b23cb7f3a045c19a78cc684613b25933d113 25241786 qemu-system-sparc-dbgsym_2.8+dfsg-1_amd64.deb
 bf9e897c2ebd2347e114d02cf8a0a0323a6fff7d 2570316 qemu-system-sparc_2.8+dfsg-1_amd64.deb
 3d79829b27d9bbde015208815c3d2bf541b0d868 35545202 qemu-system-x86-dbgsym_2.8+dfsg-1_amd64.deb
 14545350693c00451d9b52d2f73d3121bc1cb302 4810750 qemu-system-x86_2.8+dfsg-1_amd64.deb
 7caaf641960d03118e35612169303908ff530922 61866 qemu-system_2.8+dfsg-1_amd64.deb
 d3c0e5b75392c762dad50b87490c96ba57b93dce 2628 qemu-user-binfmt_2.8+dfsg-1_amd64.deb
 c3fc7c5db666654a93395e0d7c5ee459f23ca5e4 80343398 qemu-user-dbgsym_2.8+dfsg-1_amd64.deb
 bc83fdc916fc66db7fea42c15c5b3d8523be8351 88135800 qemu-user-static-dbgsym_2.8+dfsg-1_amd64.deb
 371671a57e287c3363b6b39bcc9fcc9e958b4518 8965040 qemu-user-static_2.8+dfsg-1_amd64.deb
 9d9792b35791e8c67935fe1e459c81bd2fa27491 7921790 qemu-user_2.8+dfsg-1_amd64.deb
 7fdbccdcbe35148fc8ac9ecb11c66071b79b2a22 9739264 qemu-utils-dbgsym_2.8+dfsg-1_amd64.deb
 5e4260b0e473ef478a8dc4d746a8f795e9e71dd3 980578 qemu-utils_2.8+dfsg-1_amd64.deb
 337ccd197a11482675d49def1ff256fd53deeba0 22956 qemu_2.8+dfsg-1_amd64.buildinfo
 75ec0df05c66e064cbe885fe52846cd9616e6b56 146814 qemu_2.8+dfsg-1_amd64.deb
Checksums-Sha256:
 92e0b6dea94ddcdaf8554d830e8bd0082c450505fffb23425931a27f0f998960 5596 qemu_2.8+dfsg-1.dsc
 780abde8ee1f3847bf96b2ae2515ba68bda20734ece3d1017ca6128b3b2a97a6 7040728 qemu_2.8+dfsg.orig.tar.xz
 27092aa940077f2c95fbc741daae9d6cb9ce941bb40eafa90369fd2cea778275 69456 qemu_2.8+dfsg-1.debian.tar.xz
 93e487afef8d8729dc865947947232ce19fd58ccf5cc30e81f6e50fc6d35c260 275206 qemu-block-extra-dbgsym_2.8+dfsg-1_amd64.deb
 c1d5bf0dd7941d91775715fa41b1b5a2bbe9d35fc59208f0edbc297df90d0bb7 101326 qemu-block-extra_2.8+dfsg-1_amd64.deb
 327c2cf943a664d355af90a1168d2335ce5b1b9b3d3bcd46868e757890af6dce 769340 qemu-guest-agent-dbgsym_2.8+dfsg-1_amd64.deb
 02263d3827c375c3ff0734e0406bdc9c9186b2225d3e5a9270851d6393423552 310290 qemu-guest-agent_2.8+dfsg-1_amd64.deb
 744dd641f6b3c2cbba2569e62f9dd88c29bb726bb7c13dd859256821e64e060e 62852 qemu-kvm_2.8+dfsg-1_amd64.deb
 e7cf4cddfaf9cc4eaa9e9a8f65596fcd138fe189db57656376029031a9d6b250 38352992 qemu-system-arm-dbgsym_2.8+dfsg-1_amd64.deb
 f235e4d441556d68c1bfeecadc0eebd4ca8706ba3d80ec72fdf9d542d1a40a98 5271794 qemu-system-arm_2.8+dfsg-1_amd64.deb
 15381641e29632768eba2a15abfad1c12f533454d1566b44e72880900f396ef4 327546 qemu-system-common-dbgsym_2.8+dfsg-1_amd64.deb
 4ac1d3fab8054aa54867bc10186fdf9183c6304f05440c450721a66bd17d284d 499894 qemu-system-common_2.8+dfsg-1_amd64.deb
 987bbf401d1d9df030dafd78244bf6cdb3a69401a4393b288d38845669aefd5c 64245376 qemu-system-mips-dbgsym_2.8+dfsg-1_amd64.deb
 f057eda1902506178038c58d750f7d21b0627eabe08fd7ecded42b25874a25ed 9000906 qemu-system-mips_2.8+dfsg-1_amd64.deb
 7d51db61d58d81efd83049a60f75afe9afa3b9a423fe15b4ebfbc26567ace0ed 170188102 qemu-system-misc-dbgsym_2.8+dfsg-1_amd64.deb
 1a3c519ac9166fd68557cb16d755e560d16e71854649316430a3499d8159af3a 13542652 qemu-system-misc_2.8+dfsg-1_amd64.deb
 dba8c1b6a4532842886dd8f9a4c05b34b4c8cec4d523e9200035e34686de8ecf 49329478 qemu-system-ppc-dbgsym_2.8+dfsg-1_amd64.deb
 1f6e399269c556cd0af8ad8e0acf3b5e6caf8c98f14bd881980693ef279312c0 7029742 qemu-system-ppc_2.8+dfsg-1_amd64.deb
 e5b2e39ca2aaf11fd024d700d2fa3c9a6c97285a8e41d7dbda94ad4895a5c9f5 25241786 qemu-system-sparc-dbgsym_2.8+dfsg-1_amd64.deb
 eb5da434404136974387e120c814bc68f131e1a106f4f0f1ea214b0bdfb35db7 2570316 qemu-system-sparc_2.8+dfsg-1_amd64.deb
 54db5e586120513de13bc144ab948d0349d5810b09f69e607c15c095e486fa40 35545202 qemu-system-x86-dbgsym_2.8+dfsg-1_amd64.deb
 74bcd9df243fe8a11b3291759a5118434a811dca5c3f739528b0ac0f84bba054 4810750 qemu-system-x86_2.8+dfsg-1_amd64.deb
 506fdd7b27e4286e035c6e7c54d6fbd5a54e51b0d0364917de2769be89a4aca9 61866 qemu-system_2.8+dfsg-1_amd64.deb
 5c875aa23958ec1cd5771e92c8770a2a2ea9d14f748c9db6509597446e3fb7c0 2628 qemu-user-binfmt_2.8+dfsg-1_amd64.deb
 2b9af368255d0bd099f6a4c8751f32e46174b548e42f0bdf8b81c36e876b3df3 80343398 qemu-user-dbgsym_2.8+dfsg-1_amd64.deb
 ab5f22db758b936d1f9e907aded11879991289cf2555e53ec8e1365587a6c8f0 88135800 qemu-user-static-dbgsym_2.8+dfsg-1_amd64.deb
 6c2b6e98aab83e1e7f1f94d3778b074ec076086531f3f364223de0ee4509dc51 8965040 qemu-user-static_2.8+dfsg-1_amd64.deb
 5da4a3f28b6981d07159a9520941e3b1fa590339cb7e9389f524103d1fee8c1f 7921790 qemu-user_2.8+dfsg-1_amd64.deb
 786b516b36f452e509c86f8922bad6321d566669d0be9fea8da1c5892f329209 9739264 qemu-utils-dbgsym_2.8+dfsg-1_amd64.deb
 082bd26d5f32725dbbc997487466d636ef5f45b6b41ef110c25d5162d0023aa3 980578 qemu-utils_2.8+dfsg-1_amd64.deb
 85f18188e2aaf2e53b093125bbc1ca0f4840e745bfc24b820bf1c9a2345dd799 22956 qemu_2.8+dfsg-1_amd64.buildinfo
 573f7e796cef6dbd7d8a0ec100cfbffc41aa97e16d161d4f7b21c472d7008509 146814 qemu_2.8+dfsg-1_amd64.deb
Files:
 5c26c5171904ec93e3684d9ccaec1ffc 5596 otherosfs optional qemu_2.8+dfsg-1.dsc
 998051c35e5a70e0bbab382e1046e674 7040728 otherosfs optional qemu_2.8+dfsg.orig.tar.xz
 b809def8dcb69cf4f72f8077523bd32c 69456 otherosfs optional qemu_2.8+dfsg-1.debian.tar.xz
 308a3ed3ddeb828f7675b39a3a07ccf8 275206 debug extra qemu-block-extra-dbgsym_2.8+dfsg-1_amd64.deb
 fccf1471bd8eb25807c90d2fb7b91224 101326 otherosfs optional qemu-block-extra_2.8+dfsg-1_amd64.deb
 afdaf9919f006caa49f5ec1ac51fcf91 769340 debug extra qemu-guest-agent-dbgsym_2.8+dfsg-1_amd64.deb
 420fc6386c565dfdfac3ec3ef85418a7 310290 otherosfs optional qemu-guest-agent_2.8+dfsg-1_amd64.deb
 cc2730bf6d2951207203c3937109a118 62852 otherosfs optional qemu-kvm_2.8+dfsg-1_amd64.deb
 1b50937db7824b1026959ff4f5a0a9cb 38352992 debug extra qemu-system-arm-dbgsym_2.8+dfsg-1_amd64.deb
 ba6059c132995c17d163a8fb17ca807f 5271794 otherosfs optional qemu-system-arm_2.8+dfsg-1_amd64.deb
 3d92e15091104a8056dec7a79ddd25e2 327546 debug extra qemu-system-common-dbgsym_2.8+dfsg-1_amd64.deb
 f6b091e0b5931c1dbc863149cf4f3565 499894 otherosfs optional qemu-system-common_2.8+dfsg-1_amd64.deb
 3a3525d7ebab2bc69b9a31daf840d99d 64245376 debug extra qemu-system-mips-dbgsym_2.8+dfsg-1_amd64.deb
 455f8d79864927e6ac3a835d4cf87697 9000906 otherosfs optional qemu-system-mips_2.8+dfsg-1_amd64.deb
 85c6f1bc9007d78c84bd74836dc2cf68 170188102 debug extra qemu-system-misc-dbgsym_2.8+dfsg-1_amd64.deb
 5940cff32e2795e6ad894acaf3dc2520 13542652 otherosfs optional qemu-system-misc_2.8+dfsg-1_amd64.deb
 2b1a1128f4fe1bd406c09c0bab0fe8ab 49329478 debug extra qemu-system-ppc-dbgsym_2.8+dfsg-1_amd64.deb
 b4267148c0ebf36065fbe4203fd18c85 7029742 otherosfs optional qemu-system-ppc_2.8+dfsg-1_amd64.deb
 a7532c9a57060e88611f2e5b305ab5ca 25241786 debug extra qemu-system-sparc-dbgsym_2.8+dfsg-1_amd64.deb
 7c95c587e310f0f6f90efd90b28c211c 2570316 otherosfs optional qemu-system-sparc_2.8+dfsg-1_amd64.deb
 ffb41b421c5df54a24c59c2baa208bdb 35545202 debug extra qemu-system-x86-dbgsym_2.8+dfsg-1_amd64.deb
 f5d4aa31950a94fb900c5e6e4acff4c2 4810750 otherosfs optional qemu-system-x86_2.8+dfsg-1_amd64.deb
 3093c492a2218ab49b88d18562a65bcb 61866 otherosfs optional qemu-system_2.8+dfsg-1_amd64.deb
 823415fe9eebf2451422e46369ee53a8 2628 otherosfs optional qemu-user-binfmt_2.8+dfsg-1_amd64.deb
 7ec42f38d58eee430f306fc0bd13b5b5 80343398 debug extra qemu-user-dbgsym_2.8+dfsg-1_amd64.deb
 12100d3fefbe577a2fed2aa937f3a615 88135800 debug extra qemu-user-static-dbgsym_2.8+dfsg-1_amd64.deb
 af3f7dd9fb8481142e9a5210cd71b1d1 8965040 otherosfs optional qemu-user-static_2.8+dfsg-1_amd64.deb
 31a33024bd60fb49ea31089f51e831d9 7921790 otherosfs optional qemu-user_2.8+dfsg-1_amd64.deb
 2e8893e6584f588d88571e289ee5c5d4 9739264 debug extra qemu-utils-dbgsym_2.8+dfsg-1_amd64.deb
 a14a0d854e4fa9f033d963c2bd8900c0 980578 otherosfs optional qemu-utils_2.8+dfsg-1_amd64.deb
 42e10910b0a0ecebfa22c6ff373a9346 22956 otherosfs optional qemu_2.8+dfsg-1_amd64.buildinfo
 07030a6517296019a52066989e885bcd 146814 otherosfs optional qemu_2.8+dfsg-1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJYY7m0AAoJEHAbT2saaT5ZUTsH/R/IGVyvl+ux/me6/jyA+85s
v8NqMnsNEglisVHm8Ip+VtM6RBiaFn6qin+W4l260k3pB4ntji98m+A6YxBa0jdQ
M2PBlN07ipj4S/WyeLW9cxI0ALaHwEtDP3yHBJbQ2KL2rC9btsXZRPcCQ6uqz3IX
0H4/ZsskXBy6MADk3p03DXyJvhJIXPc7BCi1wjdXC4pIfWsKbf9OL77IoARSqF3C
rGDgyGE+44xAf/gUuDiSdeXUF8V0SQCNIuUS9Dhqr7/bkEhRhmFeo6A9dpU1fuZU
PGDW7Fmt6A3EIPgSv1no/0YPY3J5hwFkAyax+965zzVTaHdcGvqbZlHcVMmQUKM=
=Nkph
-----END PGP SIGNATURE-----

Message #132 received at 813658@bugs.debian.org (full text, mbox, reply):

From: johnw <johnw.mail@gmail.com>

To: 813658@bugs.debian.org, "mjt@tls.msk.ru >> Michael Tokarev" <mjt@tls.msk.ru>

Subject: Re: Bug#813658: Please enable virgl support

Date: Thu, 29 Dec 2016 11:22:49 +0800

[Message part 1 (text/plain, inline)]

Hi, I still have some problem after upgrade qemu-system-x86 to 2.8+dfsg-1.

When I launch qemu-system-x86 with spice and gl=on, it show me error and
can not start.
 qemu-system-x86_64: -spice
unix,addr=/tmp/spice-02.sock,disable-ticketing,gl=on: Invalid parameter 'gl'

When I launch qemu-system-x86 with -display gtk,gl=on and -seccomp on,
it just freeze and "ps aux" show me.
[qemu-system-x86] <defunct>

Thanks.

[signature.asc (application/pgp-signature, attachment)]

Message #137 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: johnw <johnw.mail@gmail.com>, 813658@bugs.debian.org

Subject: Re: Bug#813658: Please enable virgl support

Date: Thu, 29 Dec 2016 09:04:58 +0300

29.12.2016 06:22, johnw wrote:
> Hi, I still have some problem after upgrade qemu-system-x86 to 2.8+dfsg-1.
> 
> When I launch qemu-system-x86 with spice and gl=on, it show me error and
> can not start.
>  qemu-system-x86_64: -spice
> unix,addr=/tmp/spice-02.sock,disable-ticketing,gl=on: Invalid parameter 'gl'

For spice it's quite expectable, we need a more recent spice for gl to
work, currently there's no released spice version with gl support, only
experimental, and it's not packaged for Debian.  I'm quite a bit nervous
to let non-released version into stable.

> When I launch qemu-system-x86 with -display gtk,gl=on and -seccomp on,
> it just freeze and "ps aux" show me.
> [qemu-system-x86] <defunct>

$ qemu-system-x86_64 -display gtk,gl=on
Couldn't open libGL.so.1: dlopen: cannot load any more object with
static TLS
$ echo $?
1
$ _

So it fails to load libGL.so

http://stackoverflow.com/questions/19268293/matlab-error-cannot-open-with-static-tls

hmm...

/mjt

Message #142 received at 813658@bugs.debian.org (full text, mbox, reply):

From: johnw <johnw.mail@gmail.com>

To: Michael Tokarev <mjt@tls.msk.ru>, 813658@bugs.debian.org

Subject: Re: Bug#813658: Please enable virgl support

Date: Thu, 29 Dec 2016 16:15:14 +0800

[Message part 1 (text/plain, inline)]

On 12/29/2016 02:04 PM, Michael Tokarev wrote:
> When I launch qemu-system-x86 with -display gtk,gl=on and -seccomp on,
>> it just freeze and "ps aux" show me.
>> [qemu-system-x86] <defunct>
> $ qemu-system-x86_64 -display gtk,gl=on
> Couldn't open libGL.so.1: dlopen: cannot load any more object with
> static TLS
> $ echo $?
> 1
> $ _
>
> So it fails to load libGL.so
>
> http://stackoverflow.com/questions/19268293/matlab-error-cannot-open-with-static-tls
>
> hmm...
>
> /mjt

Hi Michael,

Sorry, I mean "qemu-system-x86_64 -display gtk,gl=on -sandbox on",
(not -seccomp on)

when I launch -display gtk with -sandbox on, qemu-system-x86_64 will freeze,
and "ps aux" will show me [qemu-system-x86] <defunct>

I dont have problem, if launch "-display gtk" without "-sandbox on".

Thanks.

[signature.asc (application/pgp-signature, attachment)]

Message #147 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: johnw <johnw.mail@gmail.com>, 813658@bugs.debian.org

Subject: Bug#813658: Please enable virgl support

Date: Thu, 29 Dec 2016 11:43:53 +0300

29.12.2016 11:15, johnw wrote:
> Hi Michael,
> 
> Sorry, I mean "qemu-system-x86_64 -display gtk,gl=on -sandbox on",
> (not -seccomp on)
> 
> when I launch -display gtk with -sandbox on, qemu-system-x86_64 will freeze,
> and "ps aux" will show me [qemu-system-x86] <defunct>

I see, and still only with gl=on. It looks like some system call
is filtered which should not be filtered.

For quite some time, looking at the contents of syscall table which
is allowed in -sandbox mode, I see less and less reason to enable it
in the first place, because effectively all interesting system calls
are allowed anyway.  So I don't see this issue as an issue to start
with, just don't use -sandbox.

Thanks,

/mjt

> I dont have problem, if launch "-display gtk" without "-sandbox on".
> 
> Thanks.

Message #152 received at 813658@bugs.debian.org (full text, mbox, reply):

From: johnw <johnw.mail@gmail.com>

To: Michael Tokarev <mjt@tls.msk.ru>, 813658@bugs.debian.org

Subject: Re: Bug#813658: Please enable virgl support

Date: Thu, 29 Dec 2016 17:43:16 +0800

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

OK, understand now, thank you, Michael

On 2016年12月29日 GMT+08:00下午4時43分53秒, Michael Tokarev <mjt@tls.msk.ru> wrote:
>29.12.2016 11:15, johnw wrote:
>> Hi Michael,
>>
>> Sorry, I mean "qemu-system-x86_64 -display gtk,gl=on -sandbox on",
>> (not -seccomp on)
>>
>> when I launch -display gtk with -sandbox on, qemu-system-x86_64 will
>freeze,
>> and "ps aux" will show me [qemu-system-x86] <defunct>
>
>I see, and still only with gl=on. It looks like some system call
>is filtered which should not be filtered.
>
>For quite some time, looking at the contents of syscall table which
>is allowed in -sandbox mode, I see less and less reason to enable it
>in the first place, because effectively all interesting system calls
>are allowed anyway.  So I don't see this issue as an issue to start
>with, just don't use -sandbox.
>
>Thanks,
>
>/mjt
>
>> I dont have problem, if launch "-display gtk" without "-sandbox on".
>>
>> Thanks.


Key fingerprint: CDB3 6C62 254B C088 1E5D DD32 182C 97DB CF2C 80AC
-----BEGIN PGP SIGNATURE-----

iQI+BAEBCgAoIRxKb2huIFdvbmcgPGpvaG53Lm1haWxAZ21haWwuY29tPgUCWGTa
qgAKCRB0uKLLoKPihjMuEADI6RKf935kTNRnZbBO/ZavcGPu8/kkvcwURsTbPJ5i
t9+RUFzADRbqddC3eGDWM2WKelplsxPSVunCnuKfpQN/RxrHnfNYAWcApRrgMbjp
+7QasR0cJqDNVm7KJotEHmWnx+fEpCER0zskzQ0oyyX++63BcwIWwPvcHhLDiFk6
ixPTCLm3oWxup1KsYOzJZjZ9f5m4Rp3NNXxwxXdyhZCTm/FCvBuIo5/c8SzyXdQh
7UwCvXJWipdam9Ols6vmMn6APAcKEufmFN32xy0XbvUW/QDp49Q9r3+GHdIEPiRP
CLl95qroONEGi9XZf3XiHbUzrQWMerGD1S5SsDcjyllw5jldQPogWVpY4Zlv1z8h
cOSBaVjlXxe1lxzp6VQ3WUDo0Ph/MGkr7gVTL+BFcyGqBSq21aqJUM1r87BAqPlP
F9SaywZv0cFCnGlok99oaDQedXPDLt9VzYqX51PzcR4qLKMcsbqMT6kofUFj+kvw
4KzEQ07+DItV90hdYIh9r9MO4X3ju5RRsgTa7quIc7CBjtMZjDhLxjybSwsw0Vfx
YxXe06WXlbY7211iwdG/e5ZXPKjavUC3PBuNzlxNm9Pc7NYGNu8Pu4dAtGG0ENU6
RC4h8uYhnqVoOwVCGSIDy1bFUDQdlAaA1S6+BUdaWUcn92tn8JDqwm4YkLlzZEuk
MA==
=pyw5
-----END PGP SIGNATURE-----

Message #157 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Erik Adler <erik.adler@gmail.com>

To: 813658@bugs.debian.org

Subject: Re: Bug#813658: Please enable virgl support

Date: Fri, 30 Dec 2016 16:10:15 +0100

>> When I launch qemu-system-x86 with spice and gl=on, it show me error and
>> can not start.
>>  qemu-system-x86_64: -spice
>> unix,addr=/tmp/spice-02.sock,disable-ticketing,gl=on: Invalid
parameter 'gl'

> For spice it's quite expectable, we need a more recent spice for gl to
> work, currently there's no released spice version with gl support, only
> experimental, and it's not packaged for Debian.  I'm quite a bit nervous
> to let non-released version into stable.

I have packaged Spice 0.13.3 with gl support. It works fine for me but
I can understand not wanting to include experimental code. Not sure why
this branch still experimental after nine months. Anyway do as you want
with it. This code is as is.

https://github.com/adlererik/spice-virgl


###
Changes:
 spice (0.13.3-1) UNRELEASED; urgency=medium
 .
   * New upstream release
   * New git server Vcs-Git:
https://github.com/adlererik/spice-virgl-debian.git
   * Watch file will look for upstream code.
   * gl support.

Files:
 misc optional spice_0.13.3-1.dsc
 misc optional spice_0.13.3.orig.tar.bz2
 misc optional spice_0.13.3-1.debian.tar.xz
 libdevel optional libspice-server-dev_0.13.3-1_amd64.deb
 debug extra libspice-server1-dbg_0.13.3-1_amd64.deb
 libs optional libspice-server1_0.13.3-1_amd64.deb
 misc optional spice_0.13.3-1_amd64.buildinfo
###

/ Erik Adler

GPG/PGP key ID: 0x2B4B58FE
gpg --keyserver pgp.mit.edu --recv-keys 0x2B4B58FE

Message #162 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Laurent Bigonville <bigon@debian.org>

To: Erik Adler <erik.adler@gmail.com>

Cc: 813658@bugs.debian.org

Subject: Re: Bug#813658: Please enable virgl support

Date: Sat, 31 Dec 2016 14:45:08 +0100

On Fri, 30 Dec 2016 16:10:15 +0100 Erik Adler <erik.adler@gmail.com> wrote:
> >> When I launch qemu-system-x86 with spice and gl=on, it show me 
error and
> >> can not start.
> >> qemu-system-x86_64: -spice
> >> unix,addr=/tmp/spice-02.sock,disable-ticketing,gl=on: Invalid
> parameter 'gl'
>
> > For spice it's quite expectable, we need a more recent spice for gl to
> > work, currently there's no released spice version with gl support, only
> > experimental, and it's not packaged for Debian. I'm quite a bit nervous
> > to let non-released version into stable.
>
> I have packaged Spice 0.13.3 with gl support. It works fine for me but
> I can understand not wanting to include experimental code. Not sure why
> this branch still experimental after nine months. Anyway do as you want
> with it. This code is as is.
>
> https://github.com/adlererik/spice-virgl
>

I've open https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849569

Message #167 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Michael Neuffer <neuffer@neuffer.com>

To: 813658@bugs.debian.org

Subject: Re: Bug#813658: virglrenderer support before the freeze?

Date: Sat, 21 Jan 2017 14:19:23 +0100

On Mon, 14 Nov 2016 19:39:22 +0100 Andreas Cadhalpun
<andreas.cadhalpun@googlemail.com> wrote:
> The only additional dependencies compared to the current
> qemu-system-x86 package are:
> libdrm2 libepoxy0 libexpat1 libgbm1 libvirglrenderer0
> libwayland-client0 libwayland-server0
>
> That doesn't seem excessive to me.

I am tracking testing. I'll show you the new dependencies pulled in by
the qemu-system-x86 package.
When talking about dependencies do not only look at direct dependencies,
but at the whole dependency tree.
We are talking about a HUGE number of additional packages and an
increased attack surface here.

This is for qemu-system-x86 1:2.7+dfsg-3+b1 --> 1:2.8+dfsg-1

I cringe at the thought that I have to install all these packages for
quemu on what were once a really lean and clean servers
just hosting virtual machines on the net. They are getting cluttered and
keeping them secure becomes harder and harder.

A headless console-only version is surgently needed.

EIOM Pri Section  Package      Description
  _* Opt otherosf qemu-system- QEMU full system emulation binaries
(x86)                                                                                         

  _* Opt libs     libcairo2    Cairo 2D vector graphics library
  _* Opt libs     libepoxy0    OpenGL function pointer management library
  _* Opt libs     libgbm1      generic buffer management API -- runtime
  _* Opt libs     libgdk-pixbu GDK Pixbuf library
  _* Opt libs     libgtk-3-0   GTK+ graphical user interface library
  _* Xtr libs     libvirglrend virtual GPU for KVM virtualization
  _* Opt libs     libvte-2.91- Terminal emulator widget for GTK+ 3.0 -
runtime files
  __ Opt net      samba        SMB/CIFS file, print, and login server
for Unix
  __ Opt net      vde2         Virtual Distributed Ethernet
  __ Opt otherosf qemu-block-e extra block backend modules for
qemu-system and qemu-utils
  __ Opt otherosf sgabios      bios option rom to provide legacy serial
console for x86
  __ Xtr misc     ovmf         UEFI firmware for 64-bit x86 virtual machines
  _* Opt libs     libfontconfi generic font configuration library - runtime
  _* Opt libs     libxcb-rende X C Binding, render extension
  _* Opt libs     libxcb-shm0  X C Binding, shm extension
  _* Opt libs     libxrender1  X Rendering Extension client library
  _* Opt libs     libdrm2      Userspace interface to kernel DRM
services -- runtime
  _* Opt libs     libwayland-c wayland compositor infrastructure -
client library
  _* Opt libs     libwayland-s wayland compositor infrastructure -
server library
  _* Opt libs     libtiff5     Tag Image File Format (TIFF) library
  _* Opt misc     shared-mime- FreeDesktop.org shared MIME database and spec
  _* Opt libs     libgdk-pixbu GDK Pixbuf library - data files
  _* Opt misc     libgtk-3-com common files for the GTK+ graphical user
interface library
  _* Opt libs     libatk-bridg AT-SPI 2 toolkit bridge - shared library
  _* Opt libs     libatk1.0-0  ATK accessibility toolkit
  _* Opt libs     libcairo-gob Cairo 2D vector graphics library (GObject
library)
  _* Opt libs     libcolord2   system service to manage device colour
profiles -- runtime
  _* Opt libs     libcups2     Common UNIX Printing System(tm) - Core
library
  _* Opt libs     libjson-glib GLib JSON manipulation library
  _* Opt libs     libpango-1.0 Layout and rendering of internationalized
text
  _* Opt libs     libpangocair Layout and rendering of internationalized
text
  _* Opt libs     libpangoft2- Layout and rendering of internationalized
text
  _* Opt libs     librest-0.7- REST service access library
  _* Opt libs     libsoup2.4-1 HTTP library implementation in C --
Shared library
  _* Opt libs     libwayland-c wayland compositor infrastructure -
cursor library
  _* Opt libs     libwayland-e implementation of the Wayland EGL
platform -- runtime
  _* Opt libs     libxcomposit X11 Composite extension library
  _* Opt libs     libxcursor1  X cursor management library
  _* Opt libs     libxdamage1  X11 damaged region extension library
  _* Opt libs     libxfixes3   X11 miscellaneous 'fixes' extension library
  _* Opt libs     libxinerama1 X11 Xinerama extension library
  _* Opt libs     libxkbcommon library interface to the XKB compiler -
shared library
  _* Opt libs     libxrandr2   X11 RandR extension library
  _* Opt misc     hicolor-icon default fallback theme for
FreeDesktop.org icon themes
  _* Opt gnome    adwaita-icon default icon theme of GNOME
  _* Opt misc     libgtk-3-bin programs for the GTK+ graphical user
interface library
  _* Opt libs     librsvg2-com SAX-based renderer library for SVG files
(extra runtime)
  __ Opt libs     gvfs         userspace virtual filesystem - GIO module
  _* Opt libs     libpcre2-8-0 New Perl Compatible Regular Expression
Library- 8 bit runtime files
  _* Opt libs     libvte-2.91- Terminal emulator widget for GTK+ 3.0 -
common files
 *** Opt otherosf qemu-utils   QEMU utilities
  _* Opt fonts    fontconfig-c generic font configuration library -
configuration
  _* Xtr libs     libjbig0     JBIGkit libraries
  _* Opt libs     dconf-gsetti simple configuration storage system -
GSettings back-end
  __ Xtr libs     gconf-gsetti GNOME configuration database system -
GSettings back-end
  _* Opt libs     libatspi2.0- Assistive Technology Service Provider
Interface - shared
library                                                                  
  _* Opt misc     libatk1.0-da Common files for the ATK accessibility
toolkit
  _* Opt libs     liblcms2-2   Little CMS 2 color management library
  __ Opt graphics colord       system service to manage device colour
profiles -- system daemon
  __ Opt net      cups-common  Common UNIX Printing System(tm) - common
files
  _* Opt libs     libjson-glib GLib JSON manipulation library (common files)
  _* Opt fonts    fontconfig   generic font configuration library -
support binaries
  _* Opt libs     libthai0     Thai language support library
  _* Opt libs     libharfbuzz0 OpenType text shaping engine (shared library)
  _* Opt libs     libsoup-gnom HTTP library implementation in C -- GNOME
support library
  _* Opt libs     glib-network network-related giomodules for GLib
  _* Opt libs     libegl1-mesa free implementation of the EGL API -- runtime
  _* Opt misc     gtk-update-i icon theme caching utility
  _* Opt libs     librsvg2-2   SAX-based renderer library for SVG files
(runtime)
  __ Xtr admin    debootstrap  Bootstrap a basic Debian system
  _* Opt fonts    fonts-dejavu Vera font family derivate with additional
characters
  __ Opt fonts    ttf-bitstrea The Bitstream Vera family of free
TrueType fonts
  __ Opt fonts    fonts-libera Fonts with the same metrics as Times,
Arial and Courier
  _* Opt libs     dconf-servic simple configuration storage system -
D-Bus service
  _* Opt libs     libdconf1    simple configuration storage system -
runtime library
  _* Opt misc     at-spi2-core Assistive Technology Service Provider
Interface (dbus core)
  __ Opt utils    liblcms2-uti Little CMS 2 color management library
(utilities)
  _* Opt libs     libthai-data Data files for Thai language support library
  _* Opt libs     libdatrie1   Double-array trie library
  __ Opt libs     libqtcore4   Qt 4 core module
  __ Opt libs     libqtgui4    Qt 4 GUI module
  _* Opt libs     libgraphite2 Font rendering engine for Complex Scripts
-- library
  _* Opt libs     libproxy1v5  automatic proxy configuration management
library (shared)
  _* Opt libs     glib-network network-related giomodules for GLib -
D-Bus services
  _* Opt libs     glib-network network-related giomodules for GLib -
data files
  _* Opt gnome    gsettings-de GSettings desktop-wide
schemas                                                                                                    

  _* Opt libs     libxcb-dri2- X C Binding, dri2 extension
  _* Opt libs     libxcb-dri3- X C Binding, dri3 extension
  _* Opt libs     libxcb-prese X C Binding, present extension
  _* Opt libs     libxcb-sync1 X C Binding, sync extension
  _* Opt libs     libxcb-xfixe X C Binding, xfixes extension
  _* Opt libs     libxshmfence X shared memory fences - shared library
  _* Opt libs     libcroco3    Cascading Style Sheet (CSS) parsing and
manipulation toolkit
  __ Opt graphics librsvg2-bin command-line and graphical viewers for
SVG
files                                                                                  

Message #172 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Michael Neuffer <neuffer@neuffer.com>, 813658@bugs.debian.org

Subject: Re: Bug#813658: virglrenderer support before the freeze?

Date: Sat, 21 Jan 2017 18:13:33 +0300

21.01.2017 16:19, Michael Neuffer wrote:
> On Mon, 14 Nov 2016 19:39:22 +0100 Andreas Cadhalpun
> <andreas.cadhalpun@googlemail.com> wrote:
>> The only additional dependencies compared to the current
>> qemu-system-x86 package are:
>> libdrm2 libepoxy0 libexpat1 libgbm1 libvirglrenderer0
>> libwayland-client0 libwayland-server0
>>
>> That doesn't seem excessive to me.
> 
> I am tracking testing. I'll show you the new dependencies pulled in by
> the qemu-system-x86 package.
> When talking about dependencies do not only look at direct dependencies,
> but at the whole dependency tree.
> We are talking about a HUGE number of additional packages and an
> increased attack surface here.
> 
> This is for qemu-system-x86 1:2.7+dfsg-3+b1 --> 1:2.8+dfsg-1
> 
> I cringe at the thought that I have to install all these packages for
> quemu on what were once a really lean and clean servers
> just hosting virtual machines on the net. They are getting cluttered and
> keeping them secure becomes harder and harder.
> 
> A headless console-only version is surgently needed.

As I described already, even a headless version will not come without
virglrenderer, and this one does pull other things.

Creating another variant of this package (besides modular display which
wont be in stretch) does not seem to be a good idea.

I know about the amount of packages (which does not mean anything
at all, since disk space is cheap) and increased attack surface
(which is also almost a non-issue, since most of that unused stuff
is well, unused, so does not add any new risks, since debian tries
to do a good job at keeping it all secure, and due to many other
reasons).  Unless there will be separate "client-only" graphics libs
as I already described, that's how we'll live here.

Sorry I don't see a reason to create 7 more packages just for "servers",
especially since many of these will require advanced guest support
anyway such as this virgl thing.

Note some packages you mention are suggested, not even recommended.
You don't need to install recommended packages on servers.

Thanks,

/mjt

Message #177 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Hillel Lubman <shmerl@mykolab.com>

To: 813658@bugs.debian.org

Subject: Now getting: This QEMU doesn't support spice OpenGL

Date: Sun, 22 Jan 2017 16:46:35 -0500

[Message part 1 (text/plain, inline)]

Hi.

I'm on current Debian testing, and have:

qemu-*: 1:2.8+dfsg-1
libvirt0: 2.5.0-3 
libvirglrenderer0: 0.5.0-1
virt-manager: 1:1.4.0-5
libspice-server1: 0.13.3-1 (installed from: https://github.com/adlererik/spice-virgl/releases ).

And I set in my VM configuration:

    <graphics type='spice'>
      <listen type='none'/>
      <gl enable='yes'/>
    </graphics>
...
    <video>
      <model type='virtio' heads='1'/>
      <acceleration accel3d='yes'/>
    </video>

When starting the VM from virt-manager, I however get:

Error starting domain: unsupported configuration: This QEMU doesn't support spice OpenGL

The strange thing is, until recent update of libvirt*, it was starting, but initialization of virgl didn't work for some reason (I didn't yet figure out why, it was falling back to llvmpipe). Now it doesn't even start at all. What am I doing wrong, or there are some changes to libvirt now that have to be addressed?

Thanks!

[Message part 2 (text/html, inline)]

Message #178 received at 813658-done@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: Hillel Lubman <shmerl@mykolab.com>, 813658-done@bugs.debian.org

Subject: Re: Bug#813658: Now getting: This QEMU doesn't support spice OpenGL

Date: Mon, 23 Jan 2017 01:05:10 +0300

23.01.2017 00:46, Hillel Lubman wrote:
> Hi.
> 
> I'm on current Debian testing, and have:
> 
> qemu-*: 1:2.8+dfsg-1
> 
> libvirt0: 2.5.0-3
> libvirglrenderer0: 0.5.0-1
> virt-manager: 1:1.4.0-5
> 
> libspice-server1: 0.13.3-1 (installed from:
> https://github.com/adlererik/spice-virgl/releases ).

Please don't fill bug reports about software not
shipped by Debian.

Note that in order to enable opengl support in spice
in qemu, you have to build qemu with a spice wich has
opengl support.

Thanks,

/mjt

Message #179 received at 813658-done@bugs.debian.org (full text, mbox, reply):

From: Hillel Lubman <shmerl@mykolab.com>

To: Michael Tokarev <mjt@tls.msk.ru>

Cc: 813658-done@bugs.debian.org

Subject: Re: Bug#813658: Now getting: This QEMU doesn't support spice OpenGL

Date: Sun, 22 Jan 2017 17:24:40 -0500

[Message part 1 (text/plain, inline)]

On Monday, 23 January 2017 01:05:10 EST Michael Tokarev wrote:
> 
> Please don't fill bug reports about software not
> shipped by Debian.
> 
> Note that in order to enable opengl support in spice
> in qemu, you have to build qemu with a spice wich has
> opengl support.
> 
> Thanks,
> 
> /mjt
> 

Well, apparently Debian's spice doesn't support it yet, so I followed the recommendation from here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849569#10

Thanks for clarifying this dependency for qemu.

Regards,
Hillel.

[Message part 2 (text/html, inline)]

Message #184 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: 813658@bugs.debian.org, 839695@bugs.debian.org

Subject: Reverting gtk/virgl support in qemu for stretch

Date: Mon, 23 Jan 2017 14:20:56 +0300

Control: reopen 839695
Control: reopen 813658
Control: found 839695 1:2.8+dfsg-2
Control: found 813658 1:2.8+dfsg-2

I'm reverting these changes (virgl and gtk support) for stretch.

After the new qemu hit backports yesterday, I received HUGE number
of complaints, just like I expected, from "server people", including
debian server team and debian admin team, complaining about extra
dependencies.

Since this has been enabled just a month ago and haven't received
much testing, I'm reverting it for stretch, going back to old good
sdl1 frontend and without any 3d support.

We'll deal with all this during next debian release development
cycle, and the result surely will be available in backports.

Thanks,

/mjt

Message #195 received at 813658@bugs.debian.org (full text, mbox, reply):

From: "georg@riseup.net" <georg@riseup.net>

To: 813658@bugs.debian.org

Subject: Re: Reverting gtk/virgl support in qemu for stretch

Date: Mon, 23 Jan 2017 13:23:26 +0100

[Message part 1 (text/plain, inline)]

Hi Michael, all,

Thanks for reverting - the additional needed dependencies to be installed
on a headless server were just way too invasive.

Could just push this to j-bp as well?

Cheers and thanks for your work!
Best,
Georg

[signature.asc (application/pgp-signature, inline)]

Message #200 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Michael Tokarev <mjt@tls.msk.ru>

To: "georg@riseup.net" <georg@riseup.net>, 813658@bugs.debian.org

Subject: Re: Bug#813658: Reverting gtk/virgl support in qemu for stretch

Date: Mon, 23 Jan 2017 15:33:39 +0300

23.01.2017 15:23, georg@riseup.net wrote:

> 
> Could just push this to j-bp as well?

As per bpo policy, a package needs to hit testing
first. Since we're in a freeze, migration to testing
require mandatory 10 days waiting period, and should
be manually approved.  So I'm not sure it's a good
idea to push these to j-bp right away.

Thanks,

/mjt

Message #205 received at 813658@bugs.debian.org (full text, mbox, reply):

From: veshki78@vh231.sweb.ru

To: 813658@bugs.debian.org

Subject: Delivery Status Notification

Date: Thu, 27 Apr 2017 14:34:07 +0300

[Message part 1 (text/plain, inline)]

Dear Customer,

Please check your package delivery details attached!

FedEx

-----BEGIN PGP PUBLIC KEY BLOCK-----

xnUIY7N9eRD1kBCmxbeiYbqFcqZPNWtB+j7/GwPuA4UHh7b6AHlrSALX7Uv+ki1ZASb400j1CXcP
c9TSi/kGS/KObi8gEnnpEKoEHX2IFfkhFgsBoLmW+G8ziuwgdYVohce9BQkKH0sVsfbZSazTzKhl
u37bChL3wlhDweS1GsrW1DpyANEDeszCTGSyEsi024NfJgBvgrpNMB0RgtwuWO8fmXiSiGi1aN9O
jo5B0nEe++t2wuK4kYalzN5/Xs4tCu9+dXe2VPmmCu+j/DYmJbHrVatM1G6TWMjt8H+figJW/6To
17zoxKr7vTh62lAOlb57avknsj47JdqhtiEIRYACsH/adX6fVQ1L+UJzvLEr5q/urYLT3v7pHRXB
zY3Zoc1FL8ulF1ruCwUQUBejnOwRVWhGilPHlpxonu/1pf29s9hXM/uFPMI0jI1JsZTarHl4r+Mz
4Nlxv3nV/PvF0SPaABhhwdekb4yPdBNnEDNZMAjFvuiS7HoB/mYi0Q5FIeJRd4Ha1POWaj0lUbGL
QRAE1LnN/6lk/wkRdKHlAyX2naWcOoI44njBzGDPrCEtznZstrSGJb1XacDIVKVU2Nvh4bnOTJWW
3wl05a8Q5kDZM8u6lgqxCIP8pRiawn+Hfjq4omNDlnKzcHRd4qF8SCQ0z59V15UuqM3xnmIt6m6m
SQML5PqkbeW0HGKpR2k716afk+PdrDag1onAGP13W9FNMhir+Og9RIcpNphG2cOoGlH5oW10XYt/
+6doCXhyJrvRLM3IC6xO0a2vWiyisxV7CHqbOH3VlPqITTcI4aXKTkoR5QKeS1GrvxJrGy4abGqN
QykFSydwKbz4Dg9vpOqtppYtSHdAkx6R44EOfoI6HqBEd2YBdsxEMkx+RXal7ojLkgpN27EIF78X
RV5XODKudGyQOxzdX/r8+0V++ZVA55gLBwj1vbD+WuWx2GbeUZZZTWBirwI6dVzqpuE5PChfzy59
36k7EyBjakpPJrYN0W0a9sAcQ2GlrsseC+A+hzgao4VIRgoZ/7lcRS62bAeN2mAV3uuQlvgTZc/U
vtVM+M0QYZvw9Ce+BER9k27+LJmr8+DilEna8y8aPfWxMPavL3xvKMNPptYjW8MVKb6eZNaExbe/
vPtytEXrnSfMF0WL9y0AP94x8OCwqWwhZcJB/4+VS8wJo0gwIXjzA1k76Mqi2GKjgbxDvmZGrRqc
IRYxgYRmfu28l2uiviW/wsDw3zdzHprauTLu8U2gxa+tuuoQs0mFMO+wqE2PR6heyMAF2KJMDqGh
1L6hG7gwEOkdorVpd3OGo1apCynkP/Jy7rEu/nKbow==


-----END PGP PUBLIC KEY BLOCK-----

[FedEx-Label-ID-GD6R3MZV.zip (application/zip, attachment)]

Message #210 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Erik Adler <erik.adler@gmail.com>

To: 813658@bugs.debian.org

Subject: Re: Bug#813658: Please enable virgl support

Date: Fri, 26 May 2017 23:43:36 +0200

>> Hi.
>>
>> I'm on current Debian testing, and have:
>>
>> qemu-*: 1:2.8+dfsg-1
>>
>> libvirt0: 2.5.0-3
>> libvirglrenderer0: 0.5.0-1
>> virt-manager: 1:1.4.0-5
>>
>> libspice-server1: 0.13.3-1 (installed from:
>> https://github.com/adlererik/spice-virgl/releases ).
>
> Please don't fill bug reports about software not
> shipped by Debian.
>
> Note that in order to enable opengl support in spice
> in qemu, you have to build qemu with a spice wich has
> opengl support.
>
> Thanks,
>
> /mjt

I also have full QEMU builds with SPICE 0.13.3-1 for OpenGL/VirGL. Been
using then for a few months and they work very nicely. Testing full
Gnome and Unity desktop environments with acceleration with close to no
issues.

https://github.com/adlererik/qemu-virgl/releases


Erik Adler

GPG/PGP key ID: 0x2B4B58FE
gpg --keyserver pgp.mit.edu --recv-keys 0x2B4B58FE

Message #215 received at 813658@bugs.debian.org (full text, mbox, reply):

From: Hillel Lubman <shmerl@mykolab.com>

To: 813658@bugs.debian.org

Subject: Further progress?

Date: Tue, 09 Jan 2018 21:03:14 -0500

Now Debian already ships spice 0.14.0, so with this dependency issue out of the way, what else is needed
to enable virgl support in qemu? Should packages be split in some way to provide a headless variant for
those who only care about server side qemu usage and don't want many dependencies?

Regards,
Hillel Lubman.

Send a report that this bug log contains spam.