<div dir="ltr"><br><br>On Mon, Nov 4, 2019 at 1:11 PM Alexander Kanavin &lt;<a href="mailto:alex.kanavin@gmail.com">alex.kanavin@gmail.com</a>&gt; wrote:<br>&gt;<br>&gt; On Sat, 2 Nov 2019 at 23:29, Alexander Kanavin &lt;<a href="mailto:alex.kanavin@gmail.com">alex.kanavin@gmail.com</a>&gt; wrote:<br>&gt;&gt;<br>&gt;&gt; Same failures on the Debian 10 worker:<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; <a href="https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/778">https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/778</a><br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; runqemu - ERROR - Failed to run qemu: Xlib:  extension &quot;RANDR&quot; missing on display &quot;:1&quot;.<br>&gt;&gt;&gt; qemu-system-x86_64: ../libepoxy-1.5.3/src/dispatch_common.c:863: epoxy_get_proc_address: Assertion `0 &amp;&amp; &quot;Couldn&#39;t find current GLX or EGL context.\n&quot;&#39; failed.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Thanks - the Gtk part is passing fine, so it&#39;s something SDL does that upsets the X/GL stack on the Debian 10 host.<br>&gt;&gt;&gt; I am reluctant to disable the SDL part of the virgl tests on Debian 10, as it is a new distro (unlike centos 7).<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; I&#39;ll try to see if I can run Debian 10 in a VM here and try to reproduce. Or is it possible to debug directly on a Debian 10 worker?<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; So I actually went ahead, and installed Debian 10 into a qemu image, then transferred a pre-populated build directory into it, and ran runqemu there against tigervnc (hurray for the nested kvm feature!). <br>&gt;&gt;<br>&gt;&gt; Both &#39;runqemu kvm sdl gl&#39; and &#39;runqemu kvm gtk gl&#39; work fine, including running kmscube!<br>&gt;&gt;<br>&gt;&gt; So I&#39;d like to see what packages are installed on the Debian 10 worker vs. my Debian 10 installation.<br>&gt;&gt;<br>&gt;&gt; Can you issue &#39;dpkg -l&#39; on the worker, and send me the output, please? Maybe something is missing?<br>&gt;<br>&gt;<br>&gt; After additional digging I reproduced this. The culprit is the outdated VNC server implementation that runs on the Debian 10 autobuilder (and maybe others as well).<br>&gt;<br>&gt; Specifically, it&#39;s tightvncserver, where all Linux development has ceased 10 years ago (!).<br>&gt; <a href="https://www.tightvnc.com/">https://www.tightvnc.com/</a><br>&gt;<br>&gt; If you replace that with tigervnc (a modern, supported fork of tightvnc), then the tests pass fine.<br>&gt; <a href="https://tigervnc.org/">https://tigervnc.org/</a><br>&gt;<br><br>TigerVNC is now installed from the standard repos where available.<br> <br>&gt;<br>&gt; As Fedora has already obsoleted tightvnc in favor of tigervnc, I think we should do the same on all debian machines (debian provides both tightvnc and tigervnc, but treats them as equal).<br>&gt; <a href="https://src.fedoraproject.org/rpms/tightvnc/blob/master/f/dead.package">https://src.fedoraproject.org/rpms/tightvnc/blob/master/f/dead.package</a><br>&gt; I also checked that tightvnc is not available for opensuse either.<br><br><br>Server components of TigerVNC are in xorg-x11-Xvnc package which is installed on all the openSUSE workers so I expect the VNC server there to work. Please let me know if they do not.<br><br><br>On Ubuntu 16.04 and Debian 8 workers I&#39;ve installed from <a href="https://bintray.com/tigervnc/stable/tigervnc/1.9.0">https://bintray.com/tigervnc/stable/tigervnc/1.9.0</a>. This should allow tests to complete. Installing packages outside of the distribution&#39;s package manager might invalidate these as sanity tested distros. I&#39;d appreciate feedback about this.<br><br>--<br>Michael Halstead<br>Yocto Project / SysAdmin<br><br><br>&gt;<br>&gt; Alex</div>